Problem
GITTENSORY-Z (ai_review_provider_unparseable_exhausted) has been firing since 2026-07-01 (83+ occurrences, still ongoing) — the configured AI reviewer responds, but its output never contains a parseable JSON review object (hasJsonObject: false). The logged fields (model, attempt, responseChars, hasJsonObject) give no way to tell WHY: markdown code-fencing around the JSON, a response truncated mid-object, a plain-prose refusal, or something else. Sentry's own Seer analysis on this issue independently reached the same conclusion: "Log truncated response content for unparseable codex output."
Investigated live via Sentry after confirming the P0 claude-code timeout fix (#5053) was deployed and stable — this issue is NOT downstream of that outage (it kept firing hours into the post-fix, clean-boot window), so it needed its own root-cause path, currently blocked purely by missing diagnostics.
Fix
Log a bounded (400-char) prefix of the actual unparseable response text alongside the existing per-attempt/exhaustion logs in src/services/ai-review.ts's runWorkersOpinion, so the NEXT occurrence is diagnosable instead of another opaque "responseChars: N, hasJsonObject: false."
Important constraint discovered while implementing: the snippet must reach Sentry ONLY through the direct console.warn/console.log structured-log path (which the central Sentry forwarder picks up) — it must NEVER be added to the AiReviewDiagnostic/reviewDiagnostics array, because that array flows into result and public/Sentry review-failure context in a way an existing test ("single + BYOK: withholds unsafe provider and reviewer fallback text") explicitly guards against ever carrying raw provider text.
Problem
GITTENSORY-Z (
ai_review_provider_unparseable_exhausted) has been firing since 2026-07-01 (83+ occurrences, still ongoing) — the configured AI reviewer responds, but its output never contains a parseable JSON review object (hasJsonObject: false). The logged fields (model,attempt,responseChars,hasJsonObject) give no way to tell WHY: markdown code-fencing around the JSON, a response truncated mid-object, a plain-prose refusal, or something else. Sentry's own Seer analysis on this issue independently reached the same conclusion: "Log truncated response content for unparseable codex output."Investigated live via Sentry after confirming the P0 claude-code timeout fix (#5053) was deployed and stable — this issue is NOT downstream of that outage (it kept firing hours into the post-fix, clean-boot window), so it needed its own root-cause path, currently blocked purely by missing diagnostics.
Fix
Log a bounded (400-char) prefix of the actual unparseable response text alongside the existing per-attempt/exhaustion logs in
src/services/ai-review.ts'srunWorkersOpinion, so the NEXT occurrence is diagnosable instead of another opaque "responseChars: N, hasJsonObject: false."Important constraint discovered while implementing: the snippet must reach Sentry ONLY through the direct
console.warn/console.logstructured-log path (which the central Sentry forwarder picks up) — it must NEVER be added to theAiReviewDiagnostic/reviewDiagnosticsarray, because that array flows intoresultand public/Sentry review-failure context in a way an existing test ("single + BYOK: withholds unsafe provider and reviewer fallback text") explicitly guards against ever carrying raw provider text.