[Improve] Retry failed starts in a replacement task - #1747
[Improve] Retry failed starts in a replacement task#1747roomote-roomote[bot] wants to merge 1 commit into
Conversation
|
2 issues outstanding. See task
Reviewed 78a0ebb |
![roomote-community[bot]](https://avatars.githubusercontent.com/u/211522643?s=60&v=4){kind=small}
| initialTaskRun={initialTaskRun} | ||
| newTaskHref={newTaskHref} | ||
| prompt={prompt} | ||
| onRetry={() => replaceFailedStart.mutate({ runId })} |
There was a problem hiding this comment.
onRetry is now provided for every failed boot, but the session query already exposes canRetryFailedStart because not every failed run is relaunchable. For a run with messages or a non-StandardTask payload, this renders Retry and then replaceFailedStart rejects it as not found. Pass the server-derived eligibility through and omit the action when it is false.
| </Button> | ||
| </div> | ||
| )} | ||
| {isFailed ? ( |
There was a problem hiding this comment.
This also renders the snapshot-resume footer, but that caller supplies neither onRetry nor a replacement link. Since HistoricalContent gives an explicit footer precedence over its normal retry footer, failed snapshot resumes now have no recovery action at all. Preserve the prior fresh-task link or wire the existing resume retry action into this footer.
1 participant
What changed
Retryaction that creates a separate replacement task and navigates directly to it.Why this change was made
Failed Fast-delegated tasks need a fresh task identity without losing their parent session, chat thread, or lifecycle listeners. The replacement is derived entirely from persisted server state so browser input cannot spoof Fast linkage or reserved idempotency metadata.
Impact
Users can retry a failed environment start in one click and land directly on the replacement task. Fast receives the replacement's lifecycle events through the original canonical session, while canceled runs and snapshot-resume failures keep their existing behavior.
Screenshots