Visit payloads inside system Nexus envelopes#290
Draft
dplyukhin wants to merge 4 commits into
Draft
Conversation
3 tasks
tconley1428
reviewed
Jun 24, 2026
tconley1428
reviewed
Jun 24, 2026
tconley1428
reviewed
Jun 24, 2026
Opengrep — new findings
Suppress findingsAdd a |
When the payload visitor encounters a ScheduleNexusOperationCommandAttributes targeting the system Nexus endpoint (__temporal_system) and the WorkflowService, its Input is a proto-binary-serialized request whose own fields carry the user payloads rather than an opaque single payload. Decode the envelope, visit the inner payloads recursively (so external storage and codecs apply to the inner payloads, not the envelope), and re-serialize -- leaving the envelope itself un-offloaded and un-codec'd. Ordinary Nexus operations continue to visit Input as a single opaque payload. The (service, operation) -> input proto type mapping comes from a new, dependency-free `nexussystem` registry package generated by nex-gen from a checked-in WIT (nexussystem/wit), wired into the build via the `nexus-system-registry` Make target. The envelope decode/visit/encode logic lives in a hand-written proxy/system_nexus.go helper that the generated interceptor calls; only binary/protobuf envelopes are accepted.
Simplify system Nexus envelope handling per review: - Identify a system Nexus envelope solely by the reserved __temporal_system endpoint (all operations on that endpoint are system Nexus operations), instead of also matching the service name. - Decode the envelope's proto message using the payload's "messageType" metadata via protoregistry.GlobalTypes, removing the need for the generated (service, operation) -> input-type registry. The nexussystem package, its checked-in WIT, and the nexus-system-registry Make target are deleted. - Inline the system-vs-ordinary Input dispatch directly into the generated visitPayloads (the ScheduleNexusOperationCommandAttributes case) rather than a separate helper function; visitSystemNexusEnvelope remains as the envelope decode/visit/encode helper. Envelopes still must be binary/protobuf; missing/unknown message types error.
392a187 to
105dddd
Compare
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
Teaches the payload visitor to handle system Nexus envelopes. When it
encounters a
ScheduleNexusOperationCommandAttributestargeting the reservedsystem Nexus endpoint (
__temporal_system), theInputis not an opaque singlepayload — it is a proto-binary-serialized request message whose own fields carry
the user payloads. The visitor now:
messageTypemetadata (resolved viaprotoregistry.GlobalTypes).the inner payloads, not the envelope).
Input.The envelope itself is never offloaded or codec-encoded. Ordinary Nexus
operations continue to have
Inputvisited as a single opaque payload. Onlybinary/protobufenvelopes are accepted; missing/unknownmessageTypeerrors.A system Nexus envelope is identified solely by the
__temporal_systemendpoint — every operation on that endpoint is a system Nexus operation, so no
service/operation matching or operation registry is required.
How
The dispatch (system-envelope vs. ordinary single-payload) is inlined into the
generated
visitPayloads(ScheduleNexusOperationCommandAttributescase, viathe proxygenerator template). The envelope decode/visit/encode logic lives in a
hand-written
proxy/system_nexus.gohelper (visitSystemNexusEnvelope).No generated registry or WIT is needed: the input proto type comes from the
payload's
messageTypemetadata.Test plan
make proxy && (cd cmd/proxygenerator && go run ./ -verifyOnly)(generatedcode is current)
go test -tags protolegacy ./...proxy/system_nexus_test.go: nested-only visitation (sequential +concurrent), proto-binary round-trip, non-proto-binary rejection,
unknown/missing message-type rejection, ordinary-Nexus single-payload
fallback