Repository navigation
Conversation
Each client call and resource method takes `rpc_metadata` and `rpc_timeout`, and Workflow code refuses them. An `async func` operation also gets `start_<name>`, which returns the handle.
This was referenced Oct 28, 2026
Contributor
Author
|
Moved to |
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
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.
What changed?
This PR adds the RPC options to the Python client calls, and
start_<name>for an operation that WIT declaresasync func.rpc_metadata: Mapping[str, str | bytes] | None = Noneandrpc_timeout: timedelta | None = None. It passes them to_create_nexus_client, which now takes them too. So one SDK method serves every service, and the SDK applies the options to the call.ValueErrorwhen either option is set, since the options apply to calls outside a Workflow only.async funcoperation also getsstart_<name>on the client, which returns the handle of the operation. The caller awaits the handle for the result later. A call with nostart_already returns the result with one await, since feat(python): add a client target #324. The handle gives the result of the operation as it is, so an operation that returns a resource or has an output transform gets nostart_<name>.start_<name>that is also the name of another client method.A new Python sample,
client-calls, has anasync funcoperation and a plain one.TypeScript and .NET get the options with their client targets. The TypeScript client sets them with
withMetadataandwithDeadline, and a .NET call will takeRpcOptions.It sits on #327. The stack is #308, #310, #311, #297, #296, #303, #304, #309, #318, #319, #320, #321, #322, #323, #324, #325, #326, #327, then this PR.
Why?
The Stream API of the proposal has
rpc_metadataandrpc_timeouton every call, asTemporalClientcalls do. Brook's runtime uses the timeout as the deadline of the call, which it sets through aContextVartoday. A client method couldn't tell an operation that can run for a long time apart, so it couldn't give a caller the handle. WIT'sasync funcsays it.The options default to
None, not{}as in the SDK, since the samples' basedpyright refuses a mutable default.How did you test it?
The
client-callstests start theasyncoperation and check that the start returns before the result, run the plain one, and check that the RPC options reach_create_nexus_client. The stream tests check that a resource method passes its options to the client, and that the Workflow operations refuse them. A rejection fixture covers the name clash.cargo validatepasses.