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
Closes the live 500 the parity script flagged. The previous route did
prisma.taskRun.update after a findFirst that could miss; on buffered
runs (no PG row yet) the update raised RecordNotFound and surfaced as
a 500.
Switches to mutateWithFallback. PG hits go through the existing
select-dedupe-validate-update flow with MAX_TAGS_PER_RUN enforcement.
Buffered-QUEUED hits apply append_tags via Lua (atomic dedup against
existing snapshot tags). busy snapshots wait for drainer resolution
then update PG. 404 / 503 surface for missing / hung cases.
The MAX_TAGS_PER_RUN cap is skipped on the buffered side — the
drainer's engine.trigger doesn't enforce it either, matching the
pre-buffer trigger path. Pushing the cap into the snapshot-mutate Lua
is a possible follow-up.
`POST /api/v1/runs/{id}/tags` now handles buffered runs. Previously the route did `prisma.taskRun.update` after a `findFirst` that could miss; on buffered runs (no PG row yet) the update raised `RecordNotFound` and the route leaked as a 500 — the live drift the parity script flagged.
7
+
8
+
Switches the route to `mutateWithFallback` per the Q3 design. PG hits go through the existing select-dedupe-update flow with `MAX_TAGS_PER_RUN` enforcement. Buffered-QUEUED hits apply the `append_tags` patch on the snapshot (Lua-atomic dedup against existing tags). `busy` snapshots wait for drainer resolution then update PG normally. Genuine 404 / 503 surface as 404 / 503.
9
+
10
+
The `MAX_TAGS_PER_RUN` enforcement is skipped on the buffered side — the drainer's `engine.trigger` doesn't enforce it either, so behaviour matches the pre-buffer trigger path. Pushing the cap into the snapshot-mutate Lua is a possible follow-up.
0 commit comments