Implement GetWorkflowExecutionResult#10173
Implement GetWorkflowExecutionResult#10173long-nt-tran wants to merge 5 commits intotemporalio:mainfrom
Conversation
long-nt-tran
force-pushed
the
get-workflow-result
branch
10 times, most recently
from
71e932b to
9ec54e6
Compare
long-nt-tran
force-pushed
the
get-workflow-result
branch
from
9ec54e6 to
807f96b
Compare
| req.Service = cmp.Or(req.Service, "test-service") | ||
| req.Operation = cmp.Or(req.Operation, "test-operation") |
There was a problem hiding this comment.
opportunistic refactor from nexus_standalone_test.go, but maybe slightly overboard with still keeping these defaults here :) LMK if folks prefer to not have defaults at all
| leafErr := pollResp.GetFailure() | ||
| for leafErr.GetCause() != nil { | ||
| leafErr = leafErr.GetCause() | ||
| } | ||
| protorequire.ProtoEqual(s.T(), | ||
| &failurepb.Failure{Message: intentionalFailureMsg}, | ||
| leafErr, | ||
| protorequire.IgnoreFields("source", "stack_trace", "encoded_attributes", "application_failure_info"), | ||
| ) |
There was a problem hiding this comment.
this seemed slightly clunky to me but I wasn't sure there was another way to unwrap and assert on this base error, LMK if there is
|
|
||
| // Walk the CAN chain until we reach the head. At head, we will return the result of the head's workflow run, | ||
| // and optionally attach callbacks if hasCallbacks. | ||
| for range maxCANChainDepth { |
There was a problem hiding this comment.
This was what I did in my prototype, but I question if this is the right approach to have an arb. limit here. I wonder if we could be smarter but it would require a larger effort. I was thinking if we only support targeting the latest run ID then we don't need to tackle this problem yet.
There was a problem hiding this comment.
commenting for posterity per offline discussion: will always get result for latest (empty) run id for now to make this simpler
- Always default to latest runID (empty) - Incorporate latest API proto changes
2 participants
What changed?
Server PR for API counterpart temporalio/api#778
This API allows users to get the result of a workflow execution and optionally attach callbacks to be fired when the workflow completes (if the workflow is running). It follows continue-as-new chain up to
GetWorkflowExecutionResultMaxCANChainDepthiterations (for now defined to be 100 in dynamic config).A lot of boilerplate from making a new API (proto + mock generated lines). Business logic to note are in:
service/frontend/workflow_handler.goservice/history/handler.goInvoke(...)implementation:service/history/api/getworkflowexecutionresult/api.goWhy?
Allows Nexus handler to map to this operation more ergonomically for callers.
How did you test it?
Potential risks
New API -- need more test across repos (load testing, etc...). Gated behind dynamic config.