fix(batch): preserve typed error recovery signals - #1761
Conversation
|
Reviewed exact head 6cc05f7. Using the canonical DaemonError shape and conditionally copying retriable/supportedOn fixes the real batch-wrapper truncation while keeping unknown signals absent. The production route remains compatible with generic request finalization, the regression is non-vacuous, touched-file topology is healthy, and this pure wire-composition fix does not require device evidence. No source issue remains. This is not readiness-ready yet: the PR body is still the untouched template. Please document the motivating recovery-signal loss, concise summary, validation with red-before evidence, and the two-file scope. GitHub also reports zero checks for this exact head, so it cannot yet be called CI-green. Keep draft until the body and authoritative checks are complete. No ready-for-human label applied. |
|
Readiness update for unchanged exact head The only material blocker is owner approval and completion of full authoritative CI: GitHub still reports zero checks. Please also finish the body evidence with explicit two-file scope accounting and the actual red-before result, rather than only stating that coverage was added. |
Summary
Preserve structured recovery signals from a failing batch step.
DaemonErrorcan carryretriableandsupportedOn, butrunBatch()rebuilt the failing step error without forwarding either field. That meant the same underlying failure lost machine-readable recovery guidance when invoked throughbatch.This change:
retriableandsupportedOnwhen present;DaemonErrortype instead of a narrower local copy;Test plan
retriable/supportedOn.