## What's wrong 1. `EffectiveCapabilitiesService` swallows an OpenBao outage and returns an all-`false` capability map (`all_false`) with no log and no `Sentry` event. Both secrets controllers then `404`, and GraphQL `userPermissions` (`null: false` fields) returns a clean `200` claiming no permissions. [effective_capabilities_service.rb#L66-71](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/app/services/secrets_management/user_permissions/effective_capabilities_service.rb#L66-L71) / [project_secrets_manager.rb#L13-27](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/app/graphql/types/permission_types/secrets_management/project_secrets_manager.rb#L13-L27) 2. A plain `not found` (deleting or reading something that isn't there) gets misclassified as a real error, so it fires a `Sentry` event and tells the user `Internal server error` for something that isn't one. [graphql_error_handling.rb#L15-24](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/lib/secrets_management/graphql_error_handling.rb#L15-L24) / [secrets_manager_client.rb#L521](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/lib/secrets_management/secrets_manager_client.rb#L521) 3. `handle_openbao_warnings!` passes `tags:`/`extra:` as keyword args into a method that only takes positional args, so no `Sentry` tag ever lands, and the payload carries the raw secret name into both `Sentry` and `application_json.log`. [openbao_warning_handling.rb#L59-73](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/lib/secrets_management/concerns/openbao_warning_handling.rb#L59-L73) 4. `feature_category:` on the GraphQL error handler is dead — same positional-args bug, and the tag it's trying to set already exists elsewhere. [graphql_error_handling.rb#L27-32](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/lib/secrets_management/graphql_error_handling.rb#L27-L32) 5. `start_trial` has two silent rescues that report nothing anywhere. [start_trial.rb#L65-67](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/app/graphql/mutations/secrets_management/start_trial.rb#L65-L67) / [start_trial.rb#L108-112](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/app/graphql/mutations/secrets_management/start_trial.rb#L108-L112) 6. Entitlement-resolution failures use `log_exception`, which never reaches `Sentry`, at 4 of the 5 sites in scope. [resolver.rb#L99](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/lib/secrets_management/entitlement/resolver.rb#L99) / [register_job_service.rb#L81](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/app/services/ee/ci/register_job_service.rb#L81) / [secrets_read_emitter.rb#L127](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/lib/secrets_management/billable_events/secrets_read_emitter.rb#L127) / [secrets_stored_emitter.rb#L85](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/lib/secrets_management/billable_events/secrets_stored_emitter.rb#L85) ## Fixes 1. Report the rescue when it's a genuine OpenBao failure. Keep the `404` for the case where the user just has no OpenBao grant, via `ErrorMapping#permission_error?`; unthrottled `track_exception`, same pattern `HandlesGitalyErrors` already uses for a hard dependency failure. [error_mapping.rb#L10-22](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/lib/secrets_management/error_mapping.rb#L10-L22) / [handles_gitaly_errors.rb#L6-23](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/app/controllers/concerns/handles_gitaly_errors.rb#L6-L23) 2. Treat OpenBao `not found` as expected in `graphql_error_handling.rb`, so it stops reaching `Sentry` and stops returning a misleading error message. 3. Pass context as bare keyword args (drop `tags:`, `extra:`, `component:`), and swap the raw secret name for `Gitlab::Instrumentation::Openbao.operation_for` in both the `Sentry` call and the log line. Rewrite the spec, which currently pins the broken shape. [instrumentation/openbao.rb#L45-58](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/lib/gitlab/instrumentation/openbao.rb#L45-L58) / [openbao_warning_handling_spec.rb#L83-121](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/spec/lib/secrets_management/concerns/openbao_warning_handling_spec.rb#L83-L121) 4. Delete the dead `feature_category:` argument. 5. Report both rescues from inside their own rescue bodies, not through `failure_response` — that path trips `Danger`'s analytics-instrumentation gate. 6. Swap `log_exception` for `track_exception` at the 4 sites. `track_exception` logs as well, so no Kibana line is lost. No throttle: `Sentry` already groups repeats into one issue, and an unthrottled report is what `HandlesGitalyErrors` and the sibling methods in the same `CDot` REST client do. Leave `resolver.rb#L223` alone, it is already correct. [resolver.rb#L210-229](https://gitlab.com/gitlab-org/gitlab/-/blob/b101b74beda3d7397da1ebc6ab70e016d8ff7f30/ee/lib/secrets_management/entitlement/resolver.rb#L210-L229) ## References - Parent issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/611251 - Logging counterpart: https://gitlab.com/gitlab-org/gitlab/-/work_items/616113 - Sibling MR (metrics half, already merged): https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252512 - Runbooks SLI MR: https://gitlab.com/gitlab-com/runbooks/-/merge_requests/11333