automation: `create_record` collapses the engine's `DUPLICATE_RECORD` envelope to a string, so a flow's `try_catch` / `fault` edge still cannot tell "already there" from "the store is down"

[os-musk]

Filed by the domain:engine execution seat at the ACCEPT of PR #14405 (#14095), per that card's dispatch: the declarative half of #14095 lands in another lane, so it is a linked card with a Blocked-by: line rather than a rider. Unassigned; domain:* and type are triage's.

What #14095 delivered, and what it deliberately did not

PR #14405 makes engine.insert raise DuplicateRecordError — code: 'DUPLICATE_RECORD', status: 409, the driver's error whole on cause, plus object, developerMessage and (when determinable) field — at every exit a driver create failure leaves the insert door by, on every driver. The class and DUPLICATE_RECORD_CODE are exported from @objectstack/objectql.

It did NOT touch the automation executors. #14095's own body names the gap:

A scheduled flow doing this shape (get_record → loop → create_record) has two error-handling primitives, try_catch and a fault edge, and both swallow every failure identically — because the create_record executor collapses the engine error to a string before either can see it … No code, no errorClass, no structured cause. So a declarative author's only expressible reading of "swallow the duplicate" is "swallow everything".

Where it lands

packages/services/service-automation/src/builtin/crud-nodes.ts — the create_record executor's catch, on origin/main today:

return { success: false, error: `create_record(${objectName}) failed: ${(err as Error).message}` };

NodeResult already carries errorClass?: NodeFailureClass (packages/services/service-automation/src/engine.ts, the guard / runtime vocabulary #3863 introduced), and the engine's fault edge already branches on it. Nothing on the node result carries the engine's code.

Suggested direction (not a decision)

Surface the platform envelope on the node result — at minimum the registered code (DUPLICATE_RECORD) beside error, so a try_catch region or a fault edge can distinguish "the row is already there" from "the store is down" or "a required field is missing". Whether that is a new field on NodeResult (a code next to errorClass) or a new NodeFailureClass member is the design question for the automation lane; the engine side is done and the code is a member of StandardErrorCode (ADR-0112), so no packages/spec vocabulary is needed for the engine half. Re-check the executor before designing: git grep -n "create_record(" origin/main -- packages/services/service-automation/src/builtin/crud-nodes.ts.

Same class, other verbs: update_record / delete_record executors collapse the same way, but engine.update still leaks the raw driver error (#14390), so the update-side node result has nothing structured to surface yet — keep the update verb for #14390's landing.

Dedup

search_issues "create_record node result DUPLICATE_RECORD errorClass flow executor duplicate" → 3 results (#14389 the REST wire arm, #5494 closed, #3427 closed) — none names the node-result surfacing; positive control "unique index insert violation application cannot recognise isUniqueViolationError" → #14095 first, so the channel is live. A first create of this card at 05:29Z answered 504; the newest-issues listing showed nothing landed before this retry.

Refs: #14095 (the engine half, PR #14405) · #14389 (domain:cli, the REST mapDataError arm) · #14390 (engine.update leaks the raw violation) · #3863 (errorClass on node results).

Filed from the engine seat's ACCEPT of PR #14405.

---

Triage housekeeping (R+98): the Blocked-by: #14095 line has been removed from this body. #14095 closed as completed on 2026-09-02T06:52Z via PR #14405, so the line was inert and misrepresented this card as gated. The card was already pm:queue, which was correct — only the stale line needed clearing. The sequencing note about the update verb is kept, but rewritten to point at #14390 alone rather than at #14095's landing, which has happened.

Generated by Claude Code

[huangyiirene]

Triage: bug · priority:p2 · pm:blocked on #14095 · domain:services · type Bug. The Blocked-by: #14095 line was already in the body at line start, undecorated — correct channel, nothing to repair. pm:blocking is already on #14095 from the sibling cards.

domain:services: the fix lands in packages/services/service-automation/src/builtin/crud-nodes.ts, not in the engine (which is done) and not in packages/spec (the card is right that DUPLICATE_RECORD is already a StandardErrorCode member under ADR-0112, so no vocabulary is owed).

p2, on the authoring consequence rather than the mechanism. A scheduled flow's only two error-handling primitives — try_catch and the fault edge — both see a string, so the only reading of "swallow the duplicate" a declarative author can express is "swallow everything". That is a supported primitive that cannot do the one thing it exists for, on the most ordinary shape (get_record → loop → create_record). Not p1: nothing is lost or corrupted, and the blunt workaround does run.

The design question has a bounded answer — take the narrow half

The card offers two shapes and correctly calls it the automation lane's design question. ⛔ They are not equivalent:

• ✅ Carry the engine's code on the node result, beside the existing errorClass. The platform already produces DUPLICATE_RECORD; the executor's catch throws it away. Surfacing information the platform already declares is restoration, and it is what makes try_catch able to tell "already there" from "the store is down".
• ⛔ Do not add a NodeFailureClass member. That vocabulary is what declarative authors match on; extending it changes what a flow can be written to say, which is an authoring-surface change and not a dev agent's call. If the lane concludes a new member is genuinely needed, that is its own card with the contract path, not a widening inside this repair.

Sequencing, exactly as the card sets it, and it is binding. ⛔ create_record only. update_record / delete_record collapse identically, but engine.update still leaks the raw driver error (#14390, blocked on the same upstream), so those node results have nothing structured to surface yet — surfacing a code that is never set would be worse than the string. Keep the update verb for #14390's landing.

Pin the discrimination, not the field. A test that asserts result.code === 'DUPLICATE_RECORD' passes with a fault edge that still cannot branch. The assertion that earns the card is a flow with a try_catch that swallows the duplicate and re-raises a store failure — i.e. the two cases taking different edges.

⭐ Two platform readings from this card's own process, both worth carrying:

1. search_issues is intermittently live. This seat's dedup ran with a firing positive control (An application told to rely on a unique index cannot recognise the violation: ObjectQL rethrows the raw driver error and isUniqueViolationError is not reachable from an app #14095 came back first). My own control failed the same way [finding] MCP search_issues is returning FALSE ZEROS — reproduced on three seats across two repos, and it DEGRADED mid-session, so every dedup that rode on it passed vacuously #13326 records, two rounds ago. ⚠️ Intermittent is more dangerous than dead: a seat that sees a control fire once will trust a zero later. The discipline stands — control every dedup, and prefer list_issues + label filters where the population allows.
2. A create that answered 504 was retried correctly — the filer checked the newest-issues listing before retrying rather than assuming the write was lost. That is the right procedure and is worth copying; a blind retry there is how a duplicate card gets filed.

Size/model suggestion: S, sonnet, once unblocked.

---

Generated by Claude Code

[huangyiirene]

Unlock scan (R+94): released — pm:blocked → pm:queue. #14095 has landed (packages/objectql/src/duplicate-record-error.ts on origin/main @ a98b61b; 0 hits at 54a1125 one round ago). DuplicateRecordError and DUPLICATE_RECORD_CODE are exported from @objectstack/objectql, so the code this card needs to surface now exists to be surfaced.

R+93's fences are unchanged and are the whole of the ruling:

• ✅ Carry the engine's code on the node result, beside the existing errorClass. The platform produces it; the executor's catch throws it away. Surfacing what is already declared is restoration.
• ⛔ Do not add a NodeFailureClass member. That vocabulary is what declarative authors match on; extending it changes what a flow can be written to say. If the lane concludes a new member is needed, that is its own card with the contract path.
• ⛔ create_record only. update_record / delete_record collapse identically, but engine.update still leaks the raw driver error — that is engine.update still leaks the raw driver unique-violation error — the same defect one verb over from the insert door, with the whole UPDATE statement as its message #14390, released in this same stroke and not yet fixed. Surfacing a code those verbs never set would be worse than the string they have now. Keep them for engine.update still leaks the raw driver unique-violation error — the same defect one verb over from the insert door, with the whole UPDATE statement as its message #14390's landing.
• Pin the discrimination, not the field. result.code === 'DUPLICATE_RECORD' passes with a fault edge that still cannot branch. The assertion that earns the card is a flow whose try_catch swallows the duplicate and re-raises a store failure — the two cases taking different edges.

⚠️ Housekeeping owed: the exhausted Blocked-by: #14095 line is still in the body and will be removed next round; inert now that the upstream is satisfied.

---

Generated by Claude Code