## Summary While the error was logged and visible on demand in Kibana, it did not surface in the application as an error and the HTTP status code for these calls was 200 OK. This is because we swallow and log these failures [here](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/arkose/token_verification_service.rb#L46). This is a problem, because it will not affect Apdex and hence SLO trackers. ## Related Incident(s) <!-- Note the originating incident(s) and link known related incidents/other issues. The relation will happen automatically if you are creating this issue from an incident, if this isn't done already please uncomment the following line: /relate gitlab-com/gl-infra/production#ISSUE_ID --> Originating issue(s): gitlab-com/gl-infra/production#18341 ## Desired Outcome/Acceptance Criteria <!-- How will you know that this issue is complete? If you have any initial thoughts on implementation details (e.g. what to do or not do, gotchas, edge cases etc.), please share them while they are fresh in your mind. --> - [ ] Ensure that the `Arkose::TokenVerificationService` success response is consistent. Differing success payloads contributed to this incident. - [ ] Ensure the `Arkose::TokenVerificationService` does not block registration when unexpected errors happen. If the API fails with an error due to either an invalid public key or invalid session token, then the response body will be `{"error":"DENIED ACCESS","verified":"2024-08-05T19:33:44Z"}`. If the API call fails due to malformed client data in other fields then the response body will be empty. We should not surface errors to the client when the error is not `DENIED ACCESS` - [ ] Feature specs should be added to ensure we fail gracefully with unexpected arkose errors but block user actions when they are denied access. ## Associated Services <!-- Apply the appropriate services associated with this corrective action if applicable. ~Service::SERVICE_NAME /label ~"Service::SERVICE_NAME" --> ## Corrective Action Issue Checklist * [x] Link the incident(s) this corrective action arose from * [x] Give context for what problem this corrective action is trying to prevent re-occurring * [x] Assign a severity label (this is the highest sev of related incidents, defaults to 'severity::4') * [x] Assign a priority (this will default to 'Reliability::P4' but should match the severity of the related incident) * [x] Assign a service label * [x] Assign a [team label](https://handbook.gitlab.com/handbook/engineering/infrastructure/platforms/project-management/#labels)