automation: an approval node's escalation values are checked only at execution — timeoutHours 0.5 registers and activates, then every run fails and the record is created with no approval gate

[objectstack-fleet]

QA-source: #21845 · approvals.sla-escalation · outside the item's clauses

Found in the follow-up run #21845 (subject 316be321e) and reproduced by an independent verifier (RUNNER rule 7) through a second door (an authored package): medium, predates 17.6.0.

Reproduction

1. Register (admin POST /api/v1/automation, or ship in a package) an active record-triggered flow whose approval node has escalation {enabled:true, timeoutHours:0.5, action:'notify'} → 200 / loaded active.
2. Create a record that matches the trigger → 201.

• Expected: registration refuses the value (the schema says timeoutHours >= 1).
• Actual: every trigger-fired run fails with Approval node 'gate' has invalid config: escalation.timeoutHours: Too small…; no approval request opens; the record exists without the gate and the user sees nothing.

Mechanism

packages/services/service-automation/src/engine.ts (~10425-10480) checks only undeclared config key names at registration; values are parsed only at execute (packages/plugins/plugin-approvals/src/approval-node.ts:133 against approval.zod.ts:666).

Done when

Registration (and package load) runs the node's full config schema and refuses invalid values with a located error; a test covers the 0.5-hour case.

---

Generated by Claude Code

[objectstack-fleet]

Path: approvals and automation — flows run: node types, trigger types | automation.flow-node-type-matrix | P2

Triage: first grade — bug · priority:p2 · domain:services · area:workflow · pm:queue. Registration and package load run the node's full config schema

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-05T08:57Z. ⛔ Not a claim, ⛔ not a dispatch.

Triage: lands in packages/services/service-automation/src/engine.ts (registration, about :10425–:10480) ⇒ domain:services; rationale: registration checks key names only, so an invalid value is accepted and fails every run.

• Why p2. A flow with an invalid approval escalation registers as active. Every triggered run then fails, and the record is created without its approval gate, while the user sees nothing. A control silently does not hold. It predates 17.6.0.
• Direction. Registration (the admin door and package load) parses each node's config with the same schema execute uses (approval.zod.ts:666 for the approval node) and refuses with a located error. ⛔ No second, hand-written value check.
• Pins: timeoutHours: 0.5 is refused at registration through both doors, and a valid escalation still registers and runs.
• Pairs with build: objectstack validate / compile accept unknown keys in a plugin node's config (e.g. an approval node's escalation) — the build-time refusal map covers built-in node types only #21850 (the same schema, the build door).

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1 (17.7 pre-release follow-up, dispatched on the maintainer's direct order)
Session: session_018zT8d8NpiQ1ExhuNd5TxY6
Account: hotlong (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-21848-escalation-config-values
Worktree: objectstack-issue-21848
Domain: domain:services (card label, as triage set it)
File surface: packages/services/service-automation/src, .changeset/
Container & model: M, mode:subagent, model: opus (default tier; no path-derived mandate)
Clause-②: no
Thread-read: 5991301033
Serial constraints cleared: none named

Provenance: the maintainer, in Claude Code session session_018zT8d8NpiQ1ExhuNd5TxY6, 2026-10-05, verbatim: 「都开单派发」; landing per the standing order 「开发完整就进队列合并」. Dispatched one at a time within the session's load cap. Where the card withholds detail, this session holds it and the dispatch carries it privately.

---

Generated by Claude Code

[objectstack-fleet]

Release: session session_018zT8d8NpiQ1ExhuNd5TxY6 · cause: re-route before dispatch (no dev was started on this card) · destination: back to pm:queue for the domain:services lane seat to claim.

Provenance: the maintainer, in Claude Code session session_018zT8d8NpiQ1ExhuNd5TxY6, 2026-10-05, verbatim: 「只有不能公开的才需要你派发处理」. This card withholds nothing, so its dispatch belongs to the lane. The claim above is withdrawn, the assignee is cleared, and the triage grading stands.

---

Generated by Claude Code