A permit-data subagent hits a transient timeout. What error-propagation pattern is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Shake it once or twice for a flaky timeout, then send up what failed plus any partials. Local recovery first; then honest propagation.
Full Explanation
When a permit-data subagent hits a transient timeout, the appropriate pattern is to retry locally for transient faults, then propagate unresolved errors upward with partials and attempt context. Municipal permit APIs are often flaky under load; local recovery absorbs blips, while honest propagation after exhaustion keeps the coordinator informed.
Local retry then structured propagate works because timeouts are frequently temporary, yet infinite silence or fake success is worse than a clear failure. Partials (pages already fetched, IDs already resolved) and attempt context (counts, backoff, endpoints) enable the coordinator to resume, switch sources, or escalate with a complete trail for ops review.
Immediately escalating every timeout to a human without local retry fails because it floods clerks with recoverable blips and trains the system never to heal itself. Dropping the error and returning an empty success payload fails because it hides missing permit history and can cause approvals on incomplete records. Retrying forever with no propagation fails because it deadlocks the workflow and never surfaces a stuck dependency to the coordinator.
Exam caveat: retry budgets belong on transient classes (timeouts, 429/503); permanent errors (404 on a known ID, 401) should propagate sooner with the same structured context. Operational check: configure permit subagents with bounded retries on timeouts, then return failure type, attempts, partial records, and next-step hints if still unresolved.