database change LGTM 👍

@bmarjanovic could you please take it over? Thanks

What does this MR do and why?

• This MR backfills the description_versions table, setting issue_id to the value of the corresponding epic's issue_id, and setting epic_id to null.

References

• #454439

Screenshots or screen recordings

Not provided

Database

https://console.postgres.ai/gitlab/gitlab-production-main/sessions/49881/commands/148334

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #454439

Vitali Tatarintev (49a575dd) at 17 Mar 08:53

Vitali Tatarintev (503c5d69) at 17 Mar 08:53

... and 1 more commit

What does this MR do and why?

Adds a batched background migration to remove the version key from the onboarding_status JSONB column on user_details. This property was introduced for a registration experiment but is no longer used.

• Production: 0 records affected
• Staging: 39 records affected

Uses the same batched background migration approach and batch sizes as QueueRemoveExperimentsFromUserDetailsOnboardingStatus, which performed the identical operation for the experiments key on the same table.

A follow-up MR will remove the version property from the JSON schema once this migration has been confirmed to have purged all records.

Follows the removal process documented in the wiki.

Relates to #592212

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist.

Database

Migration

This is a batched background migration. Each sub-batch executes:

UPDATE user_details
SET onboarding_status = onboarding_status - 'version'
WHERE (onboarding_status ? 'version')

Given 0 rows in production, this executes instantly with no risk of timeout or lock contention.

Absolutely 👍

Purpose of revert

Causing a 500 error incident for certain customers attempting to view their projects.

Checklist

• Create an issue to reinstate the merge request and assign it to the author of the reverted merge request.
• If the revert is to resolve a broken 'master' incident, please read through the Responsibilities of the Broken master resolution DRI.
• If the revert involves a database migration, please read through Deleting existing migrations.
• Add the appropriate labels before the MR is created. We can skip CI/CD jobs only if the labels are added before the CI/CD pipeline is created.

Milestone info

• I am reverting something in the current milestone. No changelog is needed, and I've added a ~"regression:*" label.
• I am reverting something in a different milestone. A changelog is needed, and I've removed the ~"regression:*" label.

Related issues and merge requests

Thanks @Bixilon

I'm afraid we cannot apply this change, because it was fixed intentionally. I left a comment in the related issue #588801 (comment 3165280848)

I will suggest we continue discussion there. I will close the MR for now, but we can reopen it later if there is a reason for that.

What does this MR do and why?

graphql: allow unauthenticated users to query users

This is needed for viewing user profile pages. This should not impose any new risk, as all details are possible to query with html scraping. GraphQL only makes this machine readable.

Maybe removing the whole authorize! parth is better, not sure.

References

Fixes #588801

How to set up and validate locally

GraphQL request:

query {
  user(username: "bixilon") {
      username
  }
}

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

It looks like there is a reason why authentication exist Unauthenticated user can enumerate instance use... (#354209 - closed)

That's why it was fixed here Require authentication in User(s)Resolver (!88020 - merged)

I think @ifarkas can provide more context on that.

LGTM 👍

What does this MR do and why?

Adds a batched background migration to remove the version key from the onboarding_status JSONB column on user_details. This property was introduced for a registration experiment but is no longer used.

• Production: 0 records affected
• Staging: 39 records affected

Uses the same batched background migration approach and batch sizes as QueueRemoveExperimentsFromUserDetailsOnboardingStatus, which performed the identical operation for the experiments key on the same table.

A follow-up MR will remove the version property from the JSON schema once this migration has been confirmed to have purged all records.

Follows the removal process documented in the wiki.

Relates to #592212

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist.

Database

Migration

This is a batched background migration. Each sub-batch executes:

UPDATE user_details
SET onboarding_status = onboarding_status - 'version'
WHERE (onboarding_status ? 'version')

Given 0 rows in production, this executes instantly with no risk of timeout or lock contention.

Vitali Tatarintev (797cb07b) at 16 Mar 10:03

... and 1 more commit

Vitali Tatarintev (e970f763) at 16 Mar 10:02

What does this MR do and why?

Fixes non-auto-correctable Lint/EmptyBlock offenses

References

Screenshots or screen recordings

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #589138