Repository navigation
feat(workflows): per-attempt task timeout and continue-on-error - #212
Merged
Tsuyoshi Ushio (TsuyoshiUshio) merged 4 commits intoSep 16, 2026
Merged
Tsuyoshi Ushio (TsuyoshiUshio) merged 4 commits into
Tsuyoshi Ushio (TsuyoshiUshio) merged 4 commits into
Conversation
The retry foundation this slice depended on landed through PRs #193 and #207 rather than through the stale PR #186 branch, whose versions of `schema.py`, `activity.py`, and `engine.py` now conflict with the shipped contracts wholesale. Record the remaining timeout and continue-on-error slice as a clean reimplementation against current `main` instead of a rebase. The design makes all three `execution` fields optional so a deadline can be declared alone, resolves `@workflow_tool` precedence per field, bounds one attempt at the Activity boundary under a new retryable `timeout` classification, and lets a declared-continuation node commit a bounded controlled-failure result so its dependents run. Fail-fast is preserved for everything that cannot be continued: the wave selection loop keeps awaiting only when the completed instance both declared continuation and failed continuably, so a non-continuable failure never waits behind a slow sibling or a long timer. Both persisted keys are written only when authored, so a task that declares neither freezes and replays the payload the retry-only runtime wrote. An independent architecture review raised four blocking findings — whole-wave collection, unaddressed downgrade, an underspecified continuation contract, and missing coverage of mixed waves, cancellation races, and `for_each` failure shapes. Decisions 88 and 92-96 and the expanded test plan resolve them. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f32b40a3-603f-48d9-ad29-43179afe265b
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Tsuyoshi Ushio (TsuyoshiUshio)
marked this pull request as ready for review
September 15, 2026 06:00
Tsuyoshi Ushio (TsuyoshiUshio)
requested a review
from a team
as a code owner
September 15, 2026 06:00
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
hallvictoria
approved these changes
Sep 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Limit the wait for each task attempt and let a workflow continue after selected task failures.
Scope
Design only. This PR updates
docs/frds/0004-dynamic-workflows.md. It does not change runtime code.The implementation uses two stacked PRs:
execution.timeout,@workflow_tool(timeout=...), per-field precedence, and the Activity deadlineexecution.continue_on_error, bounded failure results, and continuation in both schedulersEach implementation PR includes tests, sample coverage, and user documentation. Telemetry, status changes, and UI changes are separate later work.
Design rules
handler_transientwithworkflow_task_timeout; do not add a failure kind.Limits
The one-hour admission cap is a library validation rule, not an Azure execution guarantee. Hosting-plan limits and
host.jsonsettings also apply.A timeout does not stop a running tool thread. Workflows must finish or be terminated before a runtime downgrade.