[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

[mavemuri]

placeholder until api change is merged

[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

[github-actions]

common/links.Validate has no *commonpb.Link_Workflow_ case — it falls into default: and returns InvalidArgument: "unsupported link variant" (common/links/validator.go:60-61).

That makes the link this PR returns a dead end for the main thing links are for: taking a link you got back and attaching it to a follow-up request. A client that does

qResp, _ := c.WorkflowService().QueryWorkflow(ctx, ...)
c.WorkflowService().StartWorkflowExecution(ctx, &workflowservice.StartWorkflowExecutionRequest{
    ..., Links: []*commonpb.Link{qResp.GetLink()},
})

gets InvalidArgument: unsupported link variant. Same for SignalWorkflowExecution, SignalWithStart, and UpdateWorkflowExecution (service/frontend/workflow_handler.go:693, 2241, 2286, 2350, 2445) plus the CHASM validators (chasm/lib/workflow/validator.go:220, chasm/lib/activity/link_validator.go:34).

Strictly this gap predates the PR — updateworkflow already emits Link_Workflow for rejected updates — but this change makes the variant reachable from every query response, so it's worth closing here. Adding the case alongside the Link_Activity_ one is a few lines:

case *commonpb.Link_Workflow_:
	if t.Workflow.GetNamespace() == "" {
		return serviceerror.NewInvalidArgument("workflow link must not have an empty namespace field")
	}
	if t.Workflow.GetWorkflowId() == "" {
		return serviceerror.NewInvalidArgument("workflow link must not have an empty workflow ID field")
	}
	if t.Workflow.GetRunId() == "" {
		return serviceerror.NewInvalidArgument("workflow link must not have an empty run ID field")
	}

[github-actions]

Beyond the replace placeholder you already flagged below: this line also downgrades the require from v1.63.4 (which main just moved to in #11264) to the older v1.62.15-0.20260622232249-060670b1b866 pseudo-version. The replace masks that today, so it's easy to miss — but if the replace is dropped without also restoring the require, the module silently regresses to a pre-v1.63.4 API.

When temporalio/api#842 lands, the cleanup is: delete the replace, set this back to the released tag (>= v1.63.4), and restore the two go.temporal.io/api lines that were removed from go.sum.