---
title: "Reconcile Review Runs"
method: POST
path: "/v1/internal/review-runs/reconcile"
---

# Reconcile Review Runs

`POST /v1/internal/review-runs/reconcile`

## Request

- Base URL: `https://api.graphify.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.graphify.com/v1/internal/review-runs/reconcile`
- Auth: none declared

Sweep stranded review runs to ``failed``, drain the pending review outbox, AND
re-drive READY runs whose GitHub write-back failed transiently
(``_redrive_review_writeback_failures`` -- runs whenever the GitHub App is
configured, never fails the tick).

Two independent recoveries share this one tick, mirroring
``reconcile_fv_runs``:

* The SWEEP (pure DB, ``ReviewRecoverySweeper``) runs on EVERY tick regardless
  of whether review is currently configured, so a run stranded by a mid-flight
  disable is still terminalised. A worker that dies mid-build never posts a
  terminal callback, so its run sits in ``reviewing`` / ``provisioning`` with a
  merely-EXPIRED lease -- untouched by the projector (which rejects an expired
  lease) and invisible to the outbox drain (which only re-drives ``pending``
  rows, and a stranded run is already ``enqueued``). The sweep marks every such
  run ``failed`` so a lost worker SURFACES instead of stranding forever.
* The strand RETRY (pure DB, ``StrandedReviewRetry``; DARK behind
  ``review_strand_retry_enabled``) re-dispatches what the sweep terminalised. The
  sweep's ``lease_expired`` verdict is a guess -- the run produced no result because
  the worker was reclaimed or its terminal callback never landed -- and same-head
  idempotency means only a new push re-runs it today. Bounded by
  ``recovery_attempts``; it waits out a grace, so a run swept on THIS tick is never
  retried on it (a late terminal callback, which the projector now accepts on a
  stranded run, gets first claim on delivering the real result).
* The DRAIN re-drives ``outbox_status="pending"`` rows whose SQS publish failed
  transiently -- without it a single transient publish fault stranded the
  review, unsurfaced. It no-ops (zeros) when review is not configured, so this
  tick is safe on every deployment. Re-driving is safe: ``enqueue_review``
  no-ops a run already committed as "enqueued", and the transport collapses a
  republish of the SAME run inside FIFO's dedup window (its dedup id is salted
  with the run's fixed job_id), as for the index/FV outbox siblings.
* The stuck-queued RECOVERY (pure DB, ``StuckQueuedReviewRecovery``; DARK behind
  ``stuck_queued_recovery_enabled``) remediates the class NEITHER of the above can
  reach: dispatched (``enqueued``) but NEVER-leased ``queued`` runs whose SQS
  message was dead-lettered by a capacity burst -- the sweep requires a dead lease,
  the drain only sees ``pending``. It runs BETWEEN sweep and drain so a run it
  flips back to ``pending`` is republished later this same tick. Flag off => not
  constructed at all; the tick is byte-identical to before.

## Request body

- ReconcileRequest
  - `limit` integer

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/graphify/apis/graphify-control-plane.md) · [All operations](https://skmtc.dev/graphify/apis/graphify-control-plane/llms.txt) · [OpenAPI document](https://skmtc.dev/graphify/apis/graphify-control-plane/revisions/0e75c82b5ea8?raw)