---
title: "Reconcile Group Jobs"
method: POST
path: "/v1/internal/group-jobs/reconcile"
---

# Reconcile Group Jobs

`POST /v1/internal/group-jobs/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/group-jobs/reconcile`
- Auth: none declared

Reap stranded group-merge builds to ``failed`` AND recover stuck-queued ones.

* The REAP (pure DB, ``BuildRecoverySweeper``) is the durable backstop for a group
  worker that dies mid-merge -- the fix for Graphify-Ent #117: a cross-repo union
  OOM-kills the worker mid-``building_index`` before it posts a terminal callback,
  so the build strands with an expired lease and RE-strands every time a member
  re-indexes. The reap terminalises each such build ``failed`` (releasing the lease
  and surfacing the failure) and emits ``stranded_inprogress``.
* The stuck-queued RECOVERY (pure DB, ``StuckQueuedGroupRecovery``; DARK behind
  ``stuck_queued_recovery_enabled``) remediates the class NEITHER the reap nor a
  merge trigger reaches: a merge published EXACTLY ONCE at the ``/merge`` trigger
  whose SQS message was dead-lettered by a capacity burst, sitting ``queued`` +
  never-leased forever. Unlike the index/review ticks there is NO outbox drain to
  republish a flipped row, so the recovery hands the orphans it flipped to
  ``pending`` back here and we re-publish each via ``enqueue_group_build`` (exactly
  as the ``/merge`` endpoint does, best-effort). 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)