fix: surface CI ingest failures in the PR comment

[veksen]

Why

When POST /ci/runs fails, the run silently vanishes. postToSiteApi logged a warning, returned null, and carried on — so the PR comment rendered with no dashboard link and a degraded "empty" look, the Actions check stayed green, and nothing was saved. The only trace was a line buried in the job log.

This actually happened: a Postgres-18 schema dump produced a not_null constraint type the Site API's ingest schema didn't accept, so it returned 400. 68 queries were analyzed, but the run showed up nowhere and the comment lost its link.

What a rejected ingest is

The analyzer did its whole job — captured, analyzed, dumped schema — and only the final persist step was refused. That's data loss, not a soft caveat, so it's an error worth telling the user. But the right severity and recipient depend on why it was rejected:

Kind	Cause	Recoverable	Who fixes	Behavior
transient	network / timeout / 5xx	yes (re-run)	nobody	core.warning, don't block
auth	401 / 403	no	the user (token)	core.setFailed — CI isn't running
rejected	other 4xx (contract skew)	no	us, not them	core.error (red, loud), non-blocking by default

Blocking a user's PR over our contract bug would be wrong, so rejected stays non-blocking unless a team opts in with FAIL_ON_INGEST_ERROR=true. Auth always fails (it's theirs to fix); transient never does.

Changes

• postToSiteApi returns a discriminated PostRunOutcome carrying HTTP status + a length-capped body, instead of bare null.
• classifyIngestFailure(status) → transient | auth | rejected; main.ts picks the Actions severity from it and records ingestError (with kind) on the report context.
• The comment renders a > [!CAUTION] banner with kind-specific copy (retry / fix token / out-of-sync) and a collapsible Details block (the API's error).
• FAIL_ON_INGEST_ERROR env flag (default off) to escalate rejected to a hard check failure. Flows through action.yaml's inherited env; can be promoted to a formal action input later.

Tests

• classifyIngestFailure: transient (null/5xx), auth (401/403), rejected (400/422).
• postToSiteApi: ok on 2xx; failure with status + body on non-2xx; status: null when the request never completes.
• comment banner: rejected (status + "re-running won't help" + details), auth ("Set a valid TOKEN"), transient ("re-run to retry"), and omitted on success.
• Full suite: 211+ pass, tsc --noEmit + build green. (5 suites fail to load locally on a missing pg_restore binary — pre-existing/environment, identical on a clean tree.)

Companion

Server side, handled in the Site repo: report all exceptions (incl. handled 4xx) to Sentry so this class of failure pages the operator (Query-Doctor/Site#3426). The constraint-type enum that caused the original 400 is a separate root-cause follow-up.

🤖 Generated with Claude Code

[github-actions]

Query Doctor Analysis

Caution

Query Doctor couldn't record this run. The API rejected the submission (HTTP 400), so it wasn't saved to the dashboard and the results below may be incomplete. This usually means the analyzer and Query Doctor are out of sync — re-running won't help; if it persists, it's a bug on our side.

Details

{"name":"ZodError","message":"[\n  {\n    \"code\": \"invalid_value\",\n    \"values\": [\n      \"check\",\n      \"foreign_key\",\n      \"primary_key\",\n      \"unique\",\n      \"exclusion\"\n    ],\n    \"path\": [\n      \"schema\",\n      \"constraints\",\n      0,\n      \"constraintType\"\n    ],\n    \"message\": \"Invalid option: expected one of \\\"check\\\"|\\\"foreign_key\\\"|\\\"primary_key\\\"|\\\"unique\\\"|\\\"exclusion\\\"\"\n  },\n  {\n    \"code\": \"invalid_value\",\n    \"values\": [\n      \"check\",\n      \"foreign_key\",\n      \"primary_key\",\n      \"unique\",\n …

3 queries analyzed

2 pre-existing issues

• SELECT "guests"."id", "guests"."session_id", "guests"."username", "guests"."avatar_path", "guests"."color", "guests"."side", "guests"."audio_recording_path", "guests"."audio_recording_public", "gue...
  index assets(event_id, inserted_at desc)
  cost 31,003,449 → 1,498 (100% reduction)
• SELECT * FROM guest_ip_addresses WHERE ip_address = '127.0.0.1';
  index guest_ip_addresses(ip_address)
  cost 154,402 → 8 (100% reduction)

_{Using assumed statistics (10000000 rows/table). For better results, sync production stats.}