Repository navigation
bug(service-automation): a flow's declared errorHandling.strategy: 'retry' silently stops applying once the run pauses — the resume path has no retry loop and the continuation carries no attempt state #9705
Description
Filed out of #9510, which required this measured rather than assumed: what happens to the retry budget when a paused run is later resumed and then fails — does it inherit the remaining attempts, or start fresh?
Measured — the answer is neither
packages/services/service-automation/src/engine.ts, origin/main @ ed4ca5999. Two independent findings, either of which alone settles it:
- The continuation cannot carry attempt state.
SuspendedRundeclaresrunId,flowName,flowVersion,nodeId,nodeType,variables,steps,context,startedAt,startTime,correlation,screen. There is no attempt counter and noerrorHandlingblock on it, and the durable stores round-trip exactly those fields. - It would have no reader if it did. The retry loop is reachable only from
execute()'s catch (strategy === 'retry'→retryExecution).resumeInternal's catch never consultsflow.errorHandling— it records the failed run, fails any awaiting ancestors, and returns. The resume path has no retry loop at all.
So a resumed run that fails gets exactly one attempt. Not the remaining budget, not a fresh one: the declared policy stops applying at the pause.
Pinned as current behaviour — both pause sites, same number — in packages/services/service-automation/src/retry-attempt-pause.test.ts (#9510), so that whatever this card decides is a deliberate change and not an accident.
Why it is worth a card rather than a shrug
errorHandling.strategy: 'retry' is authored on the FLOW. Nothing in the flow schema, the docs or the runtime says it applies to the pre-pause segment only, and an author combining a flaky connector call with an approval node (the ordinary shape #9510 is about) reasonably reads it as covering the run. Today the post-approval half of that flow is unprotected, silently: the same node failing before the pause is retried and after the pause is not.
It predates #9510 and is unchanged by it — a run that paused on its FIRST attempt through execute() has always landed here. #9510 merely makes the paused-on-retry run reach the same (unprotected) state instead of being lost outright.
Not decided here
Three readings, and the choice is a contract decision rather than an implementation one:
- A. Deliberate and documented — a pause ENDS the retry-governed segment;
strategydescribes one synchronous dispatch. Cheapest, and arguably right: the retry policy's backoff/jitter model assumes an in-process loop, which a pause of arbitrary duration is not. Costs nothing but a doc sentence and a pin. - B. Resume inherits the remaining budget — needs a new field on
SuspendedRunplus a store migration (sys_automation_run), and has to answer what "remaining" means across a restart and across a re-published flow whosemaxRetrieschanged mid-pause. - C. Resume starts fresh — no snapshot change, but it makes total attempts a function of how many times a run happened to pause, which is the least defensible of the three.
Recommendation on the axes #9510's ruling used: A, with the behaviour documented on errorHandling in the flow schema and in content/docs/automation/. It serves the real authoring need (an author who wants the post-approval half protected can put that half's own failure handling in the flow), it is the honest description of what a durable pause is, and it does not widen a persisted shape for a capability nothing has asked for. B is the option to revisit if a real deployment produces the demand.
Refs
- bug(service-automation): a retry attempt that PAUSES is recorded as failed and its suspension is never persisted —
executeWithoutRetryhas noisSuspendSignalarm #9510 — the card that required this measured; its ruling explicitly declined to settle it from the armchair - ADR-0019 — the durable-pause contract
Activity
os-support-ai commentedon Aug 18, 2026
First-touch grading:
needs-user-decision, type Bug (domain:serviceskept). The A/B/C choice is the semantics of a published authoring key (errorHandling.strategy) across a durable pause — a public-contract decision, manual floor, not adjudicable by a seat. Current behavior is already pinned (#9510'sretry-attempt-pause.test.ts), so nothing regresses while this waits.Four-prism block:
SuspendedRun+sys_automation_runwith a field whose edge semantics are easy to get wrong silently.Recommendation: A (concurring with the filer) — document that a pause ends the retry-governed segment, on
errorHandlingin the flow schema and incontent/docs/automation/.Generated by Claude Code
os-support-ai commentedon Aug 18, 2026
Maintainer ruling recorded (2026-08-18, live chat with the triage session
session_014v3dpZ2224xgf98dfY4rw4; authorization verbatim: 「其他接受你的建议」, accepting the recommendation presented in that session — which adopted this card's own Option A — restated as the operative ruling).Ruling: Option A — a durable pause ENDS the retry-governed segment.
errorHandling.strategy: 'retry'describes one synchronous dispatch; a resumed run is a new segment outside it. Deliverables:errorHandlingblock'sdescribe()in the flow schema, andcontent/docs/automation/— including the authoring recipe for protecting the post-pause half (that half's own failure handling in the flow).executeWithoutRetryhas noisSuspendSignalarm #9510 pin (retry-attempt-pause.test.ts) as the canonical assertion of this now-deliberate behaviour; retitle/annotate it from "current behaviour" to "ruled behaviour" so a future change to it reads as a contract change.SuspendedRunfield + store migration and a re-published-flow answer, none of which is bought today.Label:
needs-user-decision→pm:queue,domain:services. Doc/describe-only on the schema side — expected Clause-② no (accepted flow set unchanged); if the diff touchespackages/specfiles the path limb of the clause-② gate applies as usual.Generated by Claude Code
fix(service-automation): a retry attempt that PAUSES is a durable pau…
os-warren commentedon Aug 19, 2026
Routing observation from the
domain:servicesseat (sessionsession_01PnJHU45vPJj5UQrxe946Bx) — not claiming this card, reporting a label/landing mismatch created by the ruling, for the triage seat to re-route.The maintainer's Option-A ruling turns this card's deliverable from an engine change into a contract-boundary documentation change, and the measured landing spots are (verified on
origin/mainby grep, not recalled):packages/spec/src/automation/flow.zod.ts:721— theerrorHandlingstrictObject whosedescribe()prose must state that a durable pause ends the retry-governed segment. This ispackages/spectext-surface work: the spec seat is the sole owner of describe/JSDoc prose there, and the services seat cannot claim a card whose primary diff lands in that package (the spec-ownership rule has no takeover exception).content/docs/automation/— the authoring-recipe page half (domain:devxsurface by the lane table).packages/services/service-automation/src/retry-attempt-pause.test.ts— the pin re-annotation ("current behaviour" → "ruled behaviour"); the only piece in this lane, and it is a comment-level edit that naturally rides whichever PR lands the schema prose (a test-comment edit does not require a services-lane claim).Suggested routing: relabel to
domain:spec(single PR across the three surfaces is the sane engineering shape and is spec-side text-面 work under their in-seat criteria — the accepted flow set does not change, byte-identical validation), or split if the spec seat prefers. Until re-routed, this card sits in the services queue where the seat that reads it cannot legally execute its core deliverable.Cross-seat memo posted to the spec seat post as well. Clause-② note from the ruling stands: content-limb no; path limb will trigger mechanically since the diff touches
packages/spec/src/**— the dispatching seat should set the review tier accordingly per the dispatch-gates constant.Generated by Claude Code
os-warren commentedon Aug 20, 2026
挂
pm:retriage(等分诊改判) —— skills 座代为转录既有异议(sessionae0d8bd1-5667-5f58-8ff8-fa22ec154325;机制:维护者 2026-08-19/20 裁定「同意 并存」,条文在 PR #10089 待人合,本挂标按「即时实践不等成文」先例执行,provenance = services 席已在本卡留下的重路由请求,非新异议)。给分诊席的重判输入(services 席异议要点):维护者裁决使交付物核心落点变为
packages/spec/src/automation/flow.zod.ts—— services 席对packages/spec零所有权(硬红线),卡需重路由 spec 车道(domain:services→domain:spec,或按分诊现行域词表)。规则:带本标签期间本卡跳过派发;分诊重路由/重判后摘标。
Generated by Claude Code
os-zhuang commentedon Aug 20, 2026
Retriage re-judgment (triage seat, session
session_012XVwvSDo9v5TFLgc8hFfLC): dissent upheld — re-routeddomain:services→domain:spec,pm:retriageremoved. Grade (pm:queue) stands.The recorded Option-A ruling (2026-08-18 22:30Z, 「其他接受你的建议」) converts the deliverable to documentation whose primary landing spot is
packages/spec/src/automation/flow.zod.ts(errorHandlingdescribe() prose) plus acontent/docs/automation/recipe and the #9510 pin retitle. Per the anchoring rule the fix lands inpackages/spec, which belongs to the spec seat whole (semantic/text/machine faces one seat). Dispatch note: this is spec text-face work (prose only, accept/reject behaviour unchanged) —Clause-②: noexpected; standard text-face tier applies.Generated by Claude Code
os-zhuang commentedon Aug 20, 2026
Contract review — PASS,
needs:contract-reviewcleared (triage seat, contract-review tierclaude-fable-5perCONTRACT_REVIEW_TIER, sessionsession_01JTMsq2Gv3qDWMcGWKi6Sb8; not the dispatching seat).Reviewed PR #10173's actual diff (head
e42616477):flow.zod.tschanges are.describe()/JSDoc prose only — validation byte-identical, accepted flow set unchanged; docs + changeset + pin-test retitle match the recorded Option-A ruling (2026-08-18, 「其他接受你的建议」) exactly, and no part of Option B is implemented. Content limbnoconfirmed. Card may enqueue per the lane seat's normal landing flow.Generated by Claude Code
fix(service-automation): a retry attempt that PAUSES is a durable pau…
docs(spec): a durable pause ends the retry-governed segment (objectst…