[SDK Ergonomics] NEXUS-519: Support Query-backed Nexus Operations

[mavemuri]

What changed?

Adds server support for WorkflowQuery-backed Nexus Operations

Why?

Part of effort to expose all Temporal primitives as Nexus Operations

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

TODO:

• [SDK Ergonomics] NEXUS-519: Add link to QueryWorkflowResponse api#842

[github-actions]

Claude finished @mavemuri's task in 7m 1s —— View job

---

Review complete

• Read review skill + .github/copilot-instructions.md
• Analyzed the diff (common/nexus/links.go, service/history/api/queryworkflow/api.go, tests/query_workflow_test.go, go.mod/go.sum, matching test import)
• Traced the link through the frontend passthrough (workflow_handler.go:3282), common/links.Validate, and the ConvertNexusLinksToProtoLinks callers
• Posted 5 inline comments

Overall the change looks sound: the resp.GetResponse() == nil guard makes the deferred block safe on every return path, the defer is registered after the early error returns so only real responses get a link, and the functional test covers both the "Query processed" (direct-through-matching) and "Query rejected" (early-return) branches. Findings are inline — the one worth a real decision is that common/links.Validate rejects the Link_Workflow variant, so the link this PR returns can't be attached to a follow-up request.
• Branch: mavemuri/nexus-query

[long-nt-tran]

I think we definitely need a couple Nexus-based query test here as well. Off the top of my head, I think we should at least test:

1. Ongoing workflow, well-formed query (happy path)
2. Ongoing workflow, malformed query (correct error returned)
3. Completed workflow, well-formed query (and under different QueryRejectCondition states)
4. Completed workflow, malformed query (and under different QueryRejectCondition states)

When I did linking for signals I put that under tests/nexus_workflow_test.go, but feel free to make a new tests/nexus_query_test.go instead of piling on.

---

For example, here's how we'd set up such a Nexus-based test -- I'm using a Nexus signal test as a reference:

1. Map the handler (on the callee side) to a query (example with signal)
2. Map the Nexus op (on the callee side) to a query (example with signal)
3. Have a caller workflow invoke the Nexus operation (example with signal)
4. In my test I validated that the signal shows up in history, but for query I think you can validate that the query successfully returns, or some validation that indicates the expected success/failure outcome(s)

[mavemuri]

I think we definitely need a couple Nexus-based query test here as well. Off the top of my head, I think we should at least test:

1. Ongoing workflow, well-formed query (happy path)
2. Ongoing workflow, malformed query (correct error returned)
3. Completed workflow, well-formed query (and under different QueryRejectCondition states)
4. Completed workflow, malformed query (and under different QueryRejectCondition states)

When I did linking for signals I put that under tests/nexus_workflow_test.go, but feel free to make a new tests/nexus_query_test.go instead of piling on.

For example, here's how we'd set up such a Nexus-based test -- I'm using a Nexus signal test as a reference:

1. Map the handler (on the callee side) to a query (example with signal)
2. Map the Nexus op (on the callee side) to a query (example with signal)
3. Have a caller workflow invoke the Nexus operation (example with signal)
4. In my test I validated that the signal shows up in history, but for query I think you can validate that the query successfully returns, or some validation that indicates the expected success/failure outcome(s)

Agree, had added more cases in the sdk-go PR temporalio/sdk-go#2508
Will add here as well

[long-nt-tran]

Thanks for adding more tests!

[long-nt-tran]

nit: maybe send a different value to the signal handler rather than "failed" :D (i.e., "completed") I was slightly confused at first glance why "failed" meant success here

[mavemuri]

Ah sure! just wanted to convey that this is something that the completed workflow handler would return(to not confuse with "state" of workflow etc), maybe "processed" instead? will fix