feat: add explicit run resume endpoints #63
Draft
Conversation
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
hinthornw
force-pushed
the
wfh/resume
branch
from
94e7365 to
700851a
Compare
hinthornw
commented
Nov 16, 2025
Contributor
Author
There was a problem hiding this comment.
All changes are concentrated here. Other changes in this PR result from running codegen.
hinthornw
force-pushed
the
wfh/use_uv
branch
from
dc9e258 to
c576b51
Compare
hinthornw
force-pushed
the
wfh/resume
branch
from
700851a to
12d751d
Compare
- add PATCH /runs/resume, /runs/resume/wait, /runs/resume/stream to let clients resume interrupted threads (thread_id required, if_not_exists removed) - new RunResume/RunResumeStream schemas; 409 on non-interrupted threads, 404 on missing threads, same streaming shape as /runs/stream - regenerate server/client stubs from updated OpenAPI so resume handlers are wired up and return Run/RunWaitResponse/SSE with run_id in responses
hinthornw
force-pushed
the
wfh/resume
branch
from
12d751d to
dd9cd64
Compare
jdrogers940
approved these changes
Nov 24, 2025
jdrogers940
left a comment
jdrogers940
left a comment
There was a problem hiding this comment.
Nice! Some small callouts, but otherwise makes sense.
| @@ -0,0 +1,29 @@ | |||
| # StreamMode1 | |||
|
|
|||
| The stream mode(s) to use. | |||
There was a problem hiding this comment.
OOC: what's the reason for the new stream mode version?
| "title": "On Completion", | ||
| "description": "Whether to delete or keep the thread when run completes. Must be one of 'delete' or 'keep'. Defaults to 'keep'." | ||
| }, | ||
| "on_disconnect": { |
There was a problem hiding this comment.
I don't think this is applicable for the case of /runs/resume. Maybe pull out into stream and wait objects?
Comment on lines
+1854
to
+1860
| "required": [ | ||
| "run_id", | ||
| "created_at", | ||
| "updated_at", | ||
| "status", | ||
| "metadata" | ||
| ], |
There was a problem hiding this comment.
OOC: why are we including these here and not the others?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Context:
Some implementations of the Agent Protocol support "interruptions" as a way to suspend execution of an agent workflow (for e.g., user authorization flows) and later resume it with some data. Currently, the protocol is ambiguous on how this should be supported, meaning different implementations condition resuming (vs. restarting the workflow) behavior based on implementation-specific fields or conventions in the input.
This PR proposes to remove that ambiguity via an explicit set of routes to resume interrupted threads.
Proposal:
More specifically, this proposal adds three new routes
/runs/resume,/runs/resume/streamand/runs/resume/waitto mirror the existing create/wait/stream routes.They accept a payload that is nearly identical to the corresponding run creation endpoints. However, they explicitly require an underlying thread_id. It follows that the 'if_not_exists' argument is omitted for these endpoints.
If an underlying thread is not in an interrupted state, the endpoint should raise a 409 error, since the operation has a conflict with the current state of the target thread resource.
Note:
This feature implies support for the threads stage of the protocol. It is expected that resumption of a thread via
/runs/resumeor the other methods would likely create a new run to continue execution of that thread, though this is not explicitly required by the spec in this pr.This feature also still leaves the following question up to the implementation: