You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Sentry KILOCODE-WEB-1RFS: new error in production #9109
The reported production failure is a GitLab 403: the connected credential cannot create a Project Access Token for project 34 (all-tomei-projects/tomei-erp/erp-connect-api) because GitLab requires Maintainer+ (obs-code-adapter). That underlying condition is customer configuration, and the product already classifies it as action-required, disables Code Reviewer, emails the owner, and shows Maintainer-role recovery copy (obs-code-dispatch, obs-code-copy). The defect found in the pinned source is in the error-classification plumbing: gitlab-service wraps GitLabProjectAccessTokenPermissionError in a TRPCError FORBIDDEN (obs-code-wrap), so prepare-review-payload's typed permission branch (obs-code-throw) cannot match, and the intended "Maintainer role or higher on <repo>" message is never produced; the generic message that leaks the raw numeric GitLab project id is thrown instead and captured at error level (obs-code-capture) before the dispatcher can classify it as an expected, already-communicated state. Recurring Sentry noise for an expected permission gap is therefore a code-level defect, not a new product capability gap.
Recommended next step: plan. Scope a small, bounded fix on the GitLab code-review PrAT error surface: (1) make the permission failure take its intended path — classify the wrapped error (TRPCError FORBIDDEN whose cause is GitLabProjectAccessTokenPermissionError) or preserve the typed error so prepare-review-payload emits the repo-named Maintainer-role guidance instead of the generic message that leaks the numeric project id, mirroring the cause-aware handling already used for the 401 reconnect case; (2) stop reporting this expected, already-classified customer configuration state as an error-level event — either skip the captureException in prepare-review-payload for failures the dispatcher resolves as action-required, or agree that Sentry should ignore/downgrade this class. Keep the existing correct behavior: fail the review fast, disable Code Reviewer, email the owner, and show the Maintainer-role recovery copy. Any change must state both effects required by the repository's Failure-UX guidance: fewer spurious error reports and no reduction in how quickly the owner learns the real, specific reason. Do not attempt to change GitLab's Maintainer requirement; a code change cannot resolve the customer's missing role, so also note that 23KH's sibling failure mode points at the same plumbing.
Evidence unavailable: production database state (owner code-review config, review rows). Conclusions relying on those sources remain unconfirmed.
Activity
kfab-cloud commentedon Oct 29, 2026
Kfab triage
Provisional classification: suspected bug.
The reported production failure is a GitLab 403: the connected credential cannot create a Project Access Token for project 34 (all-tomei-projects/tomei-erp/erp-connect-api) because GitLab requires Maintainer+ (obs-code-adapter). That underlying condition is customer configuration, and the product already classifies it as action-required, disables Code Reviewer, emails the owner, and shows Maintainer-role recovery copy (obs-code-dispatch, obs-code-copy). The defect found in the pinned source is in the error-classification plumbing: gitlab-service wraps GitLabProjectAccessTokenPermissionError in a TRPCError FORBIDDEN (obs-code-wrap), so prepare-review-payload's typed permission branch (obs-code-throw) cannot match, and the intended "Maintainer role or higher on <repo>" message is never produced; the generic message that leaks the raw numeric GitLab project id is thrown instead and captured at error level (obs-code-capture) before the dispatcher can classify it as an expected, already-communicated state. Recurring Sentry noise for an expected permission gap is therefore a code-level defect, not a new product capability gap.
Recommended next step: plan. Scope a small, bounded fix on the GitLab code-review PrAT error surface: (1) make the permission failure take its intended path — classify the wrapped error (TRPCError FORBIDDEN whose cause is GitLabProjectAccessTokenPermissionError) or preserve the typed error so prepare-review-payload emits the repo-named Maintainer-role guidance instead of the generic message that leaks the numeric project id, mirroring the cause-aware handling already used for the 401 reconnect case; (2) stop reporting this expected, already-classified customer configuration state as an error-level event — either skip the captureException in prepare-review-payload for failures the dispatcher resolves as action-required, or agree that Sentry should ignore/downgrade this class. Keep the existing correct behavior: fail the review fast, disable Code Reviewer, email the owner, and show the Maintainer-role recovery copy. Any change must state both effects required by the repository's Failure-UX guidance: fewer spurious error reports and no reduction in how quickly the owner learns the real, specific reason. Do not attempt to change GitLab's Maintainer requirement; a code change cannot resolve the customer's missing role, so also note that 23KH's sibling failure mode points at the same plumbing.
Evidence unavailable: production database state (owner code-review config, review rows). Conclusions relying on those sources remain unconfirmed.
Sources:
Triage is complete. This recommendation does not start planning or implementation. Findings and hypotheses are available in the Kfab work item.