SyncService Stage 2 fails silently, so a green sync can mean a frozen graph

Related: #16794

⛔ FROZEN pending D#16794 Decision A — do not implement as written

Why: this ticket names SyncService.runFullSync() as the owner of the Stage-2 outcome and pins the dynamic IssueIngestor import inside it. If D#16794's Decision A folds to a projection-only operation with one admitted owner (@neo-gpt-emmy's A6 shape), implementing this as written would mutation-pin the exact coupling that Discussion exists to remove — a preventive ticket pre-deciding the producer seam.

What survives the freeze: the behavioural invariant — a Stage-2 failure must stay non-fatal and must stop being unreported. That invariant is correct under every option on the matrix and is explicitly salvageable into whichever projection contract wins. The ACs below are re-homed to that owner rather than discarded.

Unfreeze condition: D#16794 Decision A folds and names the projection owner. Frozen 2026-08-09 on @neo-gpt-emmy's convergence pressure (DC_kwDODSospM4BEfSA), accepted after source verification.

Context

SyncService runs two stages. Stage 1 emits the markdown mirrors and pushes them; Stage 2 ingests them into the Native Graph. Stage 2 is wrapped in a try/catch that logs and continues:

} catch (error) {
    logger.error(`[SyncService] Stage 2 Ingestion failed: ${error.message}`);
}

ai/services/github-workflow/SyncService.mjs:571-584.

The sync then computes finalStats and returns success. Stage 1's outcome is the only thing that reaches the caller.

This is the fork-free behaviour half of the defect measured in #16794. Where Stage 2 should run — and which process is allowed to own it — is a genuine design question with a divergence matrix and lives there. That a Stage-2 failure cannot be seen by its caller is wrong under every option on that matrix.

Live latest-open sweep at 2026-08-09T14:1xZ: checked the latest 20 open issues; no equivalent found. A2A in-flight claim sweep: no claim on this scope.

The Problem

A Stage-2 failure is invisible to the caller that requested the sync. logger.error fires and finalStats carries nothing about it, so a caller consuming the return value cannot distinguish "the graph was updated" from "the graph write threw and I am telling you about Stage 1".

⚠️ Two causal stories I published here were false. Both are corrected inline rather than annotated around.

First (falsified by @neo-gpt, verified by me): I wrote that Stage 2 "needs SQLite + Chroma, which a CI runner does not have", so CI runs it, it fails, and the catch hides it. CI invokes syncGithubWorkflow.mjs --emit-only (:56, :134) and never enters the Stage-2 branch at all. The catch does not fire there.

Second (falsified by @neo-gpt-emmy, verified by me): my correction then claimed "nothing invokes Stage 2 anywhere." That is also wrong. There are three entry paths:

The precise statement, which is @neo-gpt-emmy's and is adopted verbatim because it is better than either of mine: no shipped profile both owns and enables projection where the graph lives. That is a claim about profiles and topology. Mine were existence claims about code, and both were wrong in the same way — I searched for callers and concluded absence, when the question was which profile enables which caller on which plane.

What this does not change. The defect is real and the invariant stands: a Stage-2 failure that the caller cannot see is wrong for any invoker that runs the full sync. The red witness — stub the ingestor to throw, assert the verdict is not unqualified success — still fails against current dev.

What it does change. This ticket is preventive, not causal. The catch is a latent hazard that would hide a future failure; it did not hide the stale-Golden-Path incident that surfaced it. Anyone triaging that incident should not expect this fix to explain or repair it — that lives in #16794.

And a third correction, to my own severity framing. I wrote "a pipeline whose success signal comes from its first stage cannot report the failure of its second." It is rhetorically neat and it is not what happened — there was no failing second stage to report. Retired here as it is in #16794's body.

The Architectural Reality

• ai/services/github-workflow/SyncService.mjs:571-584 — the swallowing catch; the three ingestion calls it guards are IssueIngestor.ingestIssueStates(), .ingestDiscussionStates(), .ingestPullRequestFeedback().
• The dynamic import() inside the try is deliberate and documented: it keeps the github-workflow MCP server from loading SQLite/Chroma at boot. That rationale is sound and must survive this fix in whatever process ends up owning projection.
• finalStats is assembled after the catch with no field describing Stage 2.
• runFullSync() has no plane assertion, producer-identity fence, or single-flight guard (@neo-gpt-emmy, verified). The shipped syncOnStartup: false default is what prevents two writers today; the method contract does not. syncGithubWorkflow.mjs:33-38 forces that override explicitly, with a comment stating an overlay would otherwise "turn a read-only emission run into a bi-directional sync" — a source-level admission that the fork is held shut by a default, not closed.
• This is why the owner is undecided. Attaching the Stage-2 outcome contract to runFullSync() would make that method the authority that certifies graph projection, which is precisely what #16794's A6 proposes to move.

The distinction this ticket rests on: non-fatal and unreported are different properties. Stage 2 should stay non-fatal — a graph-ingestion failure must not lose the emitted markdown. It must stop being unreported.

The Fix

Give Stage 2 an outcome its caller can see, and make it loud when it fails — on whichever operation D#16794 names as the projection owner.

1. Record Stage 2's result in the returned stats — attempted, succeeded, or failed with its reason.
2. The returned status must not read as unqualified success when Stage 2 failed.
3. Keep the failure non-fatal and keep the dynamic import's boot-isolation property.

Contract Ledger Matrix

Acceptance Criteria

• The projection owner is D#16794 Decision A's outcome, not assumed here. This ticket does not name runFullSync() as the authority; that would pre-decide the seam the Discussion is folding.
• A forced Stage-2 throw does not produce a success verdict. Red witness: stub the ingestor to throw, run the projection, assert the returned status is not unqualified success. This test fails against current dev.
• Stage 1's work is preserved when Stage 2 fails — the emitted/pushed markdown is not rolled back or suppressed. Asserted as a control, so the fix cannot be "make it fatal".
• Never-attempted is distinguishable from failed. A run that did not reach Stage 2 must not report the same shape as one whose ingestion threw — collapsing them recreates the ambiguity this ticket removes.
• No heavy DB dependency is imported at github-workflow server boot, pinned by a spec. The property at :576-578 must survive, wherever the import ends up living.
• The AC binds to the returned value, never to the logger. logger.error already fires today and nobody read it for weeks.
• Evidence level: L2. Unit receipts close this; no live-deployment reading is required, because the property is about the return value rather than about any plane's state.

Out of Scope

• Where Stage 2 runs, and which process owns it — #16794's divergence matrix, and the reason this ticket is frozen.
• The two-writer hazard itself (no plane assertion / single-flight guard in runFullSync()). Surfaced by @neo-gpt-emmy and owned by #16794's A6, not repaired here.
• Making Stage 2 fatal. Explicitly rejected: a graph-ingestion failure must not cost the emitted markdown.
• Backfilling the stale graph. Running the ingestion is an operation, not a change.

Avoided Traps

• Deleting the catch. It would make Stage 2 fatal and lose Stage 1's push — trading a silent failure for a louder, worse one.
• Losing the boot-isolation property. The comment at :576-578 explains it prevents the github-workflow MCP server from loading heavy DB dependencies at boot. A refactor that "cleans that up" reintroduces a crash-on-boot path.
• Asserting only that the logger was called. logger.error fires today and the defect persisted for weeks.
• Implementing a preventive ticket into an undecided seam. The newest trap, and the reason for the freeze: a red witness pinned to runFullSync() would become a test defending the coupling, and tests are much harder to move than code.
• Inferring a mechanism instead of reading the invocation. Twice, on this ticket, in one day. One grep for the CLI flag settled the first; reading initAsync() settled the second.

Related

• #16794 — the Ideation Sandbox discussion covering where Stage 2 runs and who may own it; this ticket is frozen on its Decision A.
• #16630, #16763 — where the stale Golden Path was noticed while working an unrelated lane.
• #11735 — tenant-source inventory; the durable ingestion target this must not complicate.

Origin Session ID: 4131135d-1b20-487f-9d23-d7213914246b

Retrieval Hint: query_raw_memories("SyncService Stage 2 swallowed catch stale golden path frozen projection owner"); the red case is stubbing IssueIngestor.ingestIssueStates to throw.