automation: the run-resume route still answers HTTP 200 wrapping an inner {success:false} — the route #3962's status-code unification left behind

[hotlong]

Found during the ObjectStack 17.0 GA close-out of the HotCRM app (objectstack-ai/hotcrm#1156, the transfer sweep). Filed here because the fix lands in this repo, per the maintainer ruling quoted at the bottom.

The residue, and why it is being filed now

objectstack-ai/hotcrm#522 (global action dispatch fails and the UI swallows it) and objectstack-ai/hotcrm#524 (screen-flow server-side failure has no UI feedback) are both closed — their user-visible complaints were fixed and verified. But each of their closing records parks the same leftover on the other: the automation resume route still answers HTTP 200 while wrapping an inner failure. With both cards now closed, that leftover has no holder, so it is recorded here rather than dropped on the floor.

Measured

HotCRM 17.0 acceptance, independent dev server, hotcrm@0899b4f + @objectstack 17.0.0-rc.2. A screen flow (lead_conversion) driven to an engineered server-side node failure:

POST /api/v1/automation/lead_conversion/runs/run_b07d.../resume
 {"inputs":{"createOpportunity":true,"opportunityName":"A1 engineered failure","opportunityAmount":0}}

HTTP 200
{"success":true,"data":{"success":false,
 "error":"Node 'create_opportunity' failed: create_record(crm_opportunity) failed: Amount must be greater than zero"}}

summary.nodes marks create_opportunity with status:"failure". The run genuinely failed; the transport reported success.

Why this is a defect and not a preference

#3962 made exactly this argument for /actions and it was accepted before GA: business failures must not be HTTP 200 inside a double envelope. That card is closed and /actions now answers real status codes — measured on the same sweep, a script-body failure returns 400 VALIDATION_ERROR and an unknown action returns 404. The automation resume route was not part of that unification and still carries the old shape, so the platform is now internally inconsistent on the very thing #3962 set out to make uniform.

Impact is bounded, and that should be stated honestly rather than inflated: the console reads the inner envelope and surfaces the node error verbatim (verified in the same sweep — a red toast carrying the full node message), so there is no user-visible silent swallow today. That was hotcrm#522's original complaint and it is fixed. What remains is the wire contract: a scripted or integration caller that checks the HTTP status alone reads a failed run as a successful one. That is the same class of caller #3962 protected on /actions.

Adjacent observation on the same endpoint — split it out if you prefer

From the same measurement: the resume body honours only inputs / variables (plus output / branchLabel). An unknown top-level key is silently ignored — a body shaped {"nodeId":..., "values":{...}} was accepted, the submission was treated as empty, and the run completed on init_defaults and reported success.

#4477 (closed, PR #4502) tightened the inner half of this same contract: the submitted field bag is now validated against the suspended node's declared fields, and an undeclared key inside it is refused. The outer envelope is that question one level up, and it was measured lenient on 2026-08-05 — after #4502 merged. Recorded here because it is the same endpoint's request/response contract; happy for it to become its own card if triage prefers.

Not measured here

Both readings above come from the rc.2 acceptance sweep. Neither was re-measured on 17.0.0 GA, and this report contains no GA probe — the sweep that produced it was routing and bookkeeping only, with no app boot and no probe scaffolding. Re-measure before implementing.

Refs

• [17.0-rc][疑似平台] 全局（无 objectName）action 无法派发，且 UI 把失败当成功静默吞掉 hotcrm#522 (closed — dispatch + envelope; the origin of this residue)
• [17.0-rc][疑似平台] flow 型 action 菜单项无响应；screen flow 服务端失败无任何 UI 回显 hotcrm#524 (closed — screen-flow failure feedback; carried the same residue)
• [17.0.0-rc] /actions reports business failures as HTTP 200 inside a double envelope — the only route of 12 that does; unify on real status codes before GA #3962 (closed — the /actions status-code unification this route was left out of)
• [17.0.0-rc.0] Global actions unreachable: registered under key 'global', REST fallback probes '*' — and handler failures return HTTP 200 {success:true,data:{success:false}} #3913 (the original envelope report) · screen flows: resume performs no server-side validation — missing required fields and undeclared keys all complete the run #4477 / PR fix(automation,approvals): 屏幕流 resume 服务端校验 + 审批越权可审计 (#4477, #4466, #4469, #4470) #4502 (the inner-bag validation half)
• [Transfer sweep] Move all 22 platform-defect cards to the repo the fix lands in, and close them here with a pointer hotcrm#1156 (the transfer sweep this came from)

Authority

Filed under the maintainer ruling of 2026-08-14 (verbatim, untranslated):

hotcrm 席位的原则是用平台的能力做元数据应用的开发，平台的需求应该转给平台

No labels applied and no release target nominated — the transfer sweep nominates but does not label; placement is this repo's triage call.

---

Generated by Claude Code

[hotlong]

Triage: lands in packages/rest/src/rest-server.ts (the automation run-resume route — verified on origin/main @ 1eb28a1) ⇒ domain:cli (that lane owns packages/rest). Type Bug, queued.

Placement confirmed: the maintainer ruling quoted in the card (hotcrm 席位的原则是用平台的能力做元数据应用的开发，平台的需求应该转给平台) puts it in this repo, and the fix file is here. No transfer owed.

Not escalated: #3962 already ruled this exact question for /actions and it was accepted before GA. This route was left out of that unification, so the ruling is inherited rather than re-opened — reuse it, do not re-litigate the envelope shape.

⛔ Premise-first, and this one is explicit on the card: both readings come from the rc.2 sweep and neither was re-measured on 17.0.0 GA. Re-measure before implementing. premise_still_valid: false with no PR is a legitimate and useful delivery here — the route may already have been unified since.

The adjacent observation (unknown top-level keys in the resume body silently ignored, while #4477/PR #4502 tightened the inner bag) is a second card, not a rider. It is the same declared-≠-enforced shape one level up and it wants its own changeset and its own decision about breaking existing callers. File it as a separate card with a back-link if the re-measurement confirms it still reproduces on GA; do not fold it into this PR.

Size/model suggestion: S–M, opus (the re-measurement is the judgement half).

---

Generated by Claude Code

[qq9340100]

PM note — deferred this round for a serial constraint, not for priority. Staying in pm:queue, unassigned.

This card is a Bug and was otherwise next out of the domain:cli lane. It is held because #8485 (bulk-import datetime coercion) was dispatched this round and both cards land in packages/rest, with a real chance both touch rest-server.ts — which #5949 measures at ~8.6k lines and which is the repo's hottest merge-conflict surface. Two agents editing it concurrently buys nothing that waiting one merge does not.

Release condition: #8485's PR merges. Then this card is the next domain:cli dispatch.

Two things worth carrying into whoever picks this up, recorded now so they are not re-derived:

1. The card's own readings are pre-GA and it says so. Both measurements come from the rc.2 acceptance sweep and neither was re-taken on 17.0.0 GA; the card explicitly instructs a re-measure before implementing. That instruction is load-bearing here, because the whole point of the card is a wire contract — if the route's status behaviour changed between rc.2 and GA, the card is about a defect that may already be closed.

2. The adjacent observation is a second card, not a rider. The lenient outer envelope (an unknown top-level key silently ignored, so {"nodeId":…, "values":{…}} is accepted and treated as an empty submission) is a different contract question one level up from the status-code issue, and the card itself offers to split it. Split it: fixing the status code and tightening request validation are separately reviewable and separately revertable, and bundling them makes the diff hard to reason about. Whoever takes this card should file the envelope-strictness half as its own issue rather than growing this one — note that tightening an accepted request shape widens refusals on a public surface, which routes it to needs-user-decision rather than straight into the queue.

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 8
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8684-automation-resume-status-unification
Worktree: objectstack-issue-8684
Domain: domain:cli
File surface: packages/rest/src/** (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: #8485 merged as PR #8784 — the constraint that held this card is discharged. That was the whole reason for the deferral: both cards land in packages/rest and either could have touched rest-server.ts, which #5949 measures at ~8.6k lines and which is the repo's hottest conflict surface. No other in-flight card declares packages/rest; the two live domain:cli claims are #8480 (packages/client/src/**) and #8186 (packages/services/service-analytics/src/**).

Released exactly as the deferral comment said it would be, and dispatched ahead of the Task-typed backlog because it is a Bug and the lane's priority order puts type Bug above the rest.

Two things carried into the dispatch from that deferral, both of which change how this card should be worked:

1. The card's own readings are pre-GA and it says so. Both measurements come from the rc.2 acceptance sweep; neither was re-taken on 17.0.0 GA, and the card explicitly instructs a re-measure before implementing. That instruction is load-bearing here rather than boilerplate — the entire card is about a wire contract, so if the route's status behaviour changed between rc.2 and GA, the defect may already be closed and the right delivery is a measurement plus a close, not a patch.

2. The adjacent observation is a second card, not a rider. The lenient outer envelope — an unknown top-level key silently ignored, so {"nodeId":…, "values":{…}} is accepted and the submission treated as empty — is a different contract question one level up, and the card itself offers to split it. ⛔ Split it. Tightening an accepted request shape widens refusals on a public surface, which is the manual floor: it routes to needs-user-decision rather than into this PR or straight into the queue.

---

Generated by Claude Code