2023-07-11: Users are receiving 422 errors when attempting to login
Customer Impact
Users receiving 422 errors when attempting to login.
Current Status
We have started to observe a growing number of refused login attempts where the user receives a 422 error. This had the potential to impact 1056793 users.
A fix has been implemented via gitlab-org/gitlab!126013 (merged), but we cannot move forward with deploying the fix due to another ongoing incident at 2023-07-11: [CNY] FrontendServiceCnyHttpService... (#16021 - closed). We are thus rolling back production systems to the latest known good state.
The rollback has completed and error rates are back to normal. We will need to verify that gitlab-org/gitlab!126013 (merged) fixes the issue before marking the incident as resolved.
More information will be added as we investigate the issue. For customers believed to be affected by this incident, please subscribe to this issue or monitor our status page for further updates.
📝 Summary for CMOC notice / Exec summary:
- Customer Impact: A steadily increasing number receives 422 errors when tryingg to log in.
- Service Impact: ServiceFrontend
- Impact Duration: 7:05 UTC - 13:53 UTC (408 minutes)
- Root cause: A subset of users were no longer able to log in due to data not being populated in such a way to pass updated validations.
📚 References and helpful links
Recent Events (available internally only):
- Feature Flag Log - Chatops to toggle Feature Flags Documentation
- Infrastructure Configurations
- GCP Events (e.g. host failure)
Deployment Guidance
- Deployments Log | Gitlab.com Latest Updates
- Reach out to Release Managers for S1/S2 incidents to discuss Rollbacks, Hot Patching or speeding up deployments. | Rollback Runbook | Hot Patch Runbook
Use the following links to create related issues to this incident if additional work needs to be completed after it is resolved:
- Corrective action ❙ Infradev
- Incident Review ❙ Infra investigation followup
- Confidential Support contact ❙ QA investigation
Note: In some cases we need to redact information from public view. We only do this in a limited number of documented cases. This might include the summary, timeline or any other bits of information, laid out in out handbook page. Any of this confidential data will be in a linked issue, only visible internally. By default, all information we can share, will be public, in accordance to our transparency value.