Repository navigation
Conversation
`@nexus.error` on an enum makes a class per case of a failed call, under one base. Python's operations objects raise the class of a failed call's reason from the original error.
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
@nexus.error, which maps the cases of an error enum to exception classes.@nexus.errormakes a class per case that has the directive, under one base.detailsandfieldname the record and its field that carry the case in a failed call.<language>-basenames the SDK class that the base extends, and a language with none gets no classes.StreamErrorin Python and TypeScript, andStreamExceptionin .NET. A case class is the stem, the case without the enum's prefix, and the suffix, such asStreamSeqDivergentError.nameand<language>-nameon a case override it.retryable=true. Its failure type is the class name, and its details hold the details record, so it survives a Local Activity.errors.pywithstream_error(details, message), TypeScript giveserrors.tswithstreamError(details, message), and .NET givesErrors.cswithStreamErrors.From(details, message)._support.error_details(err, StreamErrorDetails), and raises the mapped class from the original error. Other errors propagate.nexgen refuses an enum
@nexus.errorwith nodetails,fieldorbase, adetailsthat isn't a record of the interface, afieldthat doesn't hold the enum, a case@nexus.errorwith none on the enum, two cases with one class name, aretryablethat isn'ttrueorfalse, and two error enums in one interface.The stream sample takes the error directives of Brook's next WIT. The sample support gives
error_details, which finds the details record in the cause chain of a Nexus operation failure or of an Activity error, as the model or as the proto message.It sits on #334. The stack is #308, #310, #311, #297, #296, #303, #304, #309, #318, #319, #320, #321, #322, #323, #324, #325, #326, #327, #328, #329, #330, #331, #332, #333, #334, then this PR.
Why?
The Stream API of the proposal raises one error class per Store reason, such as
StreamNotFoundError. The facade maps the reasons by hand today, in_errors.py.TypeScript and .NET get the classes and the mapping function, but their operations don't convert failures yet. The conversion sits in the operations objects, and those come with their client targets. The design passed
int(reason)as the detail. This PR passes the details record, so the support helper finds it as the same type on both sides.How did you test it?
Python tests check that a reason gives its class and retryability, that a reason with no class and an unknown reason give the base class, and that the details come from a Nexus operation failure and from a Local Activity's error. Others check that a client call raises the class of its reason from the original error, that a call with no reason raises its own error, and that a Workflow resource method raises the class of a Local Activity failure. TypeScript and .NET tests check that a reason gives its class and retryability, and the base class for the others. A Go test checks the warning, a unit test checks the directive, and rejection fixtures cover each refusal.
cargo validatepasses.