You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 4021096
Browse filesBrowse the repository at this point in the historyBrowse files
fix(webapp): anchor batch item run-ops residency to the batch friendlyId
On the v4 (RunEngine V2) batch paths, RunEngineBatchTriggerService (api.v2) and
the BatchQueue item callback (api.v3), a parentless batch's item runs minted
their run-ops residency from a fresh per-org flag read at processing time. A
mint-flag flip between batch creation and item processing could then mint an
item into a different physical store than its BatchTaskRun row: an FK violation
against the run-ops DB's live TaskRun_batchId_fkey (batch on legacy, item on
new), or a silent orphan (batch on new, item on legacy).
Anchor each item's mint on the batch's own friendlyId (pure id-shape, zero new
queries), mirroring the already-safe BatchTriggerV3Service, and anchor the
pre-failed-run fallback the same way since it also sets batchId. Consolidate the
shared id-generation branch into mintFriendlyIdForKind so every mint path stays
in lockstep. Single-DB mode is unchanged: a cuid-shaped batch friendlyId yields
a cuid item.
Anchor batch item run-ops residency on the batch's own friendlyId (not a fresh per-org flag read) in the run-engine batch trigger service and the BatchQueue item callback, on both the success path and the pre-failed-run failure path, so a mid-batch mint-flag flip can no longer mint an item (or a pre-failed item) into a different physical store than its BatchTaskRun row.
0 commit comments