Add callback support for standalone activities by fretz12 · Pull Request #9786 · temporalio/temporal

fretz12 · 2026-04-02T15:36:12Z

What changed?

Added completion callback support to standalone activities:

Callback lifecycle: When a standalone activity reaches a terminal state (completed, failed, canceled, terminated, timed out), it now fires any registered Nexus completion callbacks — the same mechanism workflows already use.
Frontend validation: Callback URL length, header size, and endpoint allowlist validation is now shared between workflows and standalone activities via callbacks.ValidateCallbacks, refactored out of the workflow handler.
Describe response: DescribeActivityExecution now returns callback state (CallbackInfo) including trigger, status, attempt count, and failure details.
Start response: StartActivityExecutionResponse now includes a Link_Activity_ identifying the started (or reused) activity.
Config: Renamed MaxCHASMCallbacksPerWorkflow to MaxCallbacksPerExecution since it now applies to both workflows and standalone activities.

Why?

The v2 scheduler needs to start standalone activities on a schedule and be notified when they complete, so it can track action results, handle overlap policies, and support pause-on-failure. Workflows already have this via CompletionCallbacks + Nexus callback delivery. This PR gives standalone activities the same capability, reusing the existing callback library rather than reimplementing the
delivery/retry/backoff logic. This is a prerequisite for the scheduler's Invoker to call StartActivityExecution with a callback pointing back to the Scheduler component.

How did you test it?

bergundy

The logic you've added LGTM overall, here are the gaps:

Missing validation in the frontend for the callbacks.
Missing callback info in the describe response.
Missing returning links in the StartActivityExecution response.

Copilot

Pull request overview

Adds Nexus completion-callback support to standalone activities, reusing the existing callbacks library/validation used by workflows, and renames the CHASM callback limit dynamic config to apply to both workflows (CHASM path) and standalone activities.

Changes:

Attach/validate CompletionCallbacks on StartActivityExecution for standalone activities and trigger delivery on terminal activity close.
Centralize callback validation in components/callbacks.ValidateCallbacks and reuse it for workflow start validation.
Rename dynamic config from MaxCHASMCallbacksPerWorkflow to MaxCallbacksPerExecution, and extend functional tests for callbacks + response link fields.

Reviewed changes

Copilot reviewed 13 out of 14 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
tests/standalone_activity_test.go	Adds functional coverage for callback acceptance, describe visibility, and delivery on activity terminal states.
service/history/workflow/mutable_state_impl.go	Switches CHASM workflow callback cap to `MaxCallbacksPerExecution`.
service/history/configs/config.go	Wires new `MaxCallbacksPerExecution` config getter into history config.
service/frontend/workflow_handler.go	Replaces local workflow callback validation with shared `callbacks.ValidateCallbacks`.
components/callbacks/config.go	Introduces shared `ValidateCallbacks` and internalizes URL allowlist validation helpers.
components/callbacks/config_test.go	Adds unit tests for `ValidateCallbacks`; updates allowlist tests to new internal method name.
common/dynamicconfig/constants.go	Renames/defines `MaxCallbacksPerExecution` dynamic config setting and description.
chasm/lib/activity/frontend.go	Validates/normalizes callbacks on StartActivityExecution requests for standalone activities.
chasm/lib/activity/config.go	Adds callback-related dynamic config accessors to standalone activity config.
chasm/lib/activity/handler.go	Persists callbacks on activity start and returns an Activity link in StartActivityExecutionResponse.
chasm/lib/activity/activity.go	Stores callbacks on the activity, triggers them on close, and surfaces callback info in DescribeActivityExecution.
go.mod / go.sum	Bumps `go.temporal.io/api` dependency to a newer dev revision.
cmd/tools/getproto/files.go	Removes a stray leading line from generated file header.

fretz12 · 2026-04-07T17:11:22Z

 	}

+	if cbs := req.GetCompletionCallbacks(); len(cbs) > 0 {
+		if err := callbacks.ValidateCallbacks(


I'd prefer to force all errors in callbacks.ValidateCallbacks to return serviceerrors, but didn't want to break anything existing. Open to advice here

I'd be fine if you switched to service errors. That's very common in the codebase. It's technically redundant because it adds a header with a serialized proto that most SDKs don't care about (only Go SDK does).

lina-temporal · 2026-04-07T21:48:21Z

+		cbInfos = append(cbInfos, &workflowpb.CallbackInfo{
+			Callback: cbSpec,
+			// WorkflowClosed is the only trigger variant in the proto.
+			Trigger:                 &workflowpb.CallbackInfo_Trigger{Variant: &workflowpb.CallbackInfo_Trigger_WorkflowClosed{}},


What about adding a separate trigger variant for standalone activities? I can see us not wanting to move CallbackInfo from workflowpb because of backwards compatibility, but this feels like something we could introduce more easily now than later. If this has already been discussed and decided, that's fine too.

Yes! That was caught in the API PR. It's now activity specific too

dandavison

Looks great, I did a pass and made some suggestions.

My main concern is it's not clear to me that we should release this using the workflow CallbackInfo. We'll want to straighten that out in the future, but that would be a backwards incompatible API change. So it seems to me that we need to straighten that out now.

dandavison · 2026-04-03T20:38:40Z

+	return srv.URL
+}
+
+func (s *standaloneActivityTestSuite) TestCallbacks() {


As I suggested above, would be good to add coverage of the timeout cases since they can cause attempt.CompleteTime not to be set.

Yes, added tests for all terminal cases

dandavison · 2026-04-09T13:00:57Z

+			return serviceerror.NewInvalidArgumentf("unsupported callback variant: %T", variant)
+		}
+
+		id := fmt.Sprintf("%s-%d", requestID, idx)


Can we add a comment explaining what desirable properties follow from this ID-naming scheme (and add the same comment to chasm/lb/workflow/workflow.go.

Can someone confirm that the ID naming scheme used by HSM callbacks, which was designed to address a replication concern that I haven't fully understood yet, is not required by CHASM workflow/SAA callbacks?

https://github.com/temporalio/temporal/blob/main/service/history/workflow/mutable_state_impl.go#L3174-L3176

Added a comment, please double check accuracy folks

No need to mention HSM here IMHO.

dandavison · 2026-04-09T13:17:19Z

+		opts.Error = opErr
+	}
+
+	return opts, nil


It should either be success or failure, so we don't expect to get here. WDYT about:

Suggested change

opts.Error = opErr

}

return opts, nil

opts.Error = opErr

return opts, nil

}

return nexusrpc.CompleteOperationOptions{}, serviceerror.NewInternalf("activity in status %v has no outcome", a.Status)

dandavison · 2026-04-09T13:24:03Z

+		if details := attempt.GetLastFailureDetails(); details != nil {
+			failure = details.GetFailure()
+		}
+	}


We do this check-in-two-places-for-a-failure logic in another place. I worry that something will forget to do it in the future. Adding a documented helper would reduce that risk. WDYT about introducing this helper:

diff

diff --git a/chasm/lib/activity/activity.go b/chasm/lib/activity/activity.go index 43f583674..8cf5a583a 100644 --- a/chasm/lib/activity/activity.go +++ b/chasm/lib/activity/activity.go @@ -362,16 +362,7 @@ func (a *Activity) GetNexusCompletion(ctx chasm.Context, _ string) (nexusrpc.Com return opts, nil } - var failure *failurepb.Failure - if f := outcome.GetFailed(); f != nil { - failure = f.GetFailure() - } - if failure == nil { - if details := attempt.GetLastFailureDetails(); details != nil { - failure = details.GetFailure() - } - } - + failure := a.terminalFailure(ctx) if failure != nil { state := nexus.OperationStateFailed message := "operation failed" @@ -947,15 +938,23 @@ func (a *Activity) outcome(ctx chasm.Context) *apiactivitypb.ActivityExecutionOu Value: &apiactivitypb.ActivityExecutionOutcome_Result{Result: successful.GetOutput()}, } } - if failure := activityOutcome.GetFailed().GetFailure(); failure != nil { + if failure := a.terminalFailure(ctx); failure != nil { return &apiactivitypb.ActivityExecutionOutcome{ Value: &apiactivitypb.ActivityExecutionOutcome_Failure{Failure: failure}, } } + return nil +} + +// terminalFailure returns the failure for a closed activity. The failure may be stored in +// Outcome.Failed (terminated, canceled, timed out) or in LastAttempt.LastFailureDetails +// (failed after exhausting retries). Returns nil if no failure is found. +func (a *Activity) terminalFailure(ctx chasm.Context) *failurepb.Failure { + if f := a.Outcome.Get(ctx).GetFailed(); f != nil { + return f.GetFailure() + } if details := a.LastAttempt.Get(ctx).GetLastFailureDetails(); details != nil { - return &apiactivitypb.ActivityExecutionOutcome{ - Value: &apiactivitypb.ActivityExecutionOutcome_Failure{Failure: details.GetFailure()}, - } + return details.GetFailure() } return nil }

dandavison · 2026-04-09T13:33:02Z

+		}
+	}
+	return nil
+}


This is an identical copy of the function used for workflow CHASM callbacks: https://github.com/temporalio/temporal/blob/main/chasm/lib/workflow/workflow.go#L56

That suggests that it should be moved into chasm/lib/callback.

dandavison · 2026-04-09T13:55:23Z

+	attempt := a.LastAttempt.Get(ctx)
+	opts := nexusrpc.CompleteOperationOptions{
+		StartTime: attempt.GetStartedTime().AsTime(),
+		CloseTime: attempt.GetCompleteTime().AsTime(),


There's a little bug here. This isn't set on schedule-to-start and schedule-to-close timeouts, nor when terminated in SCHEDULED state. I believe the fix is

Suggested change

CloseTime: attempt.GetCompleteTime().AsTime(),

CloseTime: ctx.ExecutionInfo().CloseTime,

Failing test case

t.Run("ScheduleToStartTimeoutWithCallbacks", func(t *testing.T) { activityID := testcore.RandomizeStr(t.Name()) taskQueue := testcore.RandomizeStr(t.Name()) ch := &completionHandler{ requestCh: make(chan *nexusrpc.CompletionRequest, 1), requestCompleteCh: make(chan error, 1), } defer func() { close(ch.requestCh) close(ch.requestCompleteCh) }() callbackAddress := s.runNexusCompletionHTTPServer(t, ch) _, err := s.FrontendClient().StartActivityExecution(ctx, &workflowservice.StartActivityExecutionRequest{ Namespace: s.Namespace().String(), ActivityId: activityID, ActivityType: s.tv.ActivityType(), Identity: s.tv.WorkerIdentity(), Input: defaultInput, TaskQueue: &taskqueuepb.TaskQueue{ Name: taskQueue, }, StartToCloseTimeout: durationpb.New(1 * time.Minute), ScheduleToStartTimeout: durationpb.New(1 * time.Second), RequestId: s.tv.Any().String(), CompletionCallbacks: []*commonpb.Callback{{ Variant: &commonpb.Callback_Nexus_{Nexus: &commonpb.Callback_Nexus{Url: callbackAddress}}, }}, }) require.NoError(t, err) // No worker polls -- activity will time out waiting to be started. // Verify the callback is delivered with failure state and non-zero CloseTime. select { case completion := <-ch.requestCh: require.Equal(t, nexus.OperationStateFailed, completion.State) var failureErr *nexus.FailureError require.ErrorAs(t, completion.Error.Cause, &failureErr) require.Contains(t, failureErr.Failure.Message, "ScheduleToStart") // StartTime may be zero (activity was never started), but CloseTime must not be. require.False(t, completion.CloseTime.IsZero(), "CloseTime must not be zero for a timed-out activity") ch.requestCompleteCh <- nil case <-ctx.Done(): require.Fail(t, "timed out waiting for completion callback") } descResp, err := s.FrontendClient().DescribeActivityExecution(ctx, &workflowservice.DescribeActivityExecutionRequest{ Namespace: s.Namespace().String(), ActivityId: activityID, }) require.NoError(t, err) require.Equal(t, enumspb.ACTIVITY_EXECUTION_STATUS_TIMED_OUT, descResp.GetInfo().GetStatus()) })

Good catch. Changed. Also added extra tests for all terminal states

bergundy

You're missing the ability to attach callbacks to a running activity when use existing is specified. You'll want to express that with on_conflict_options on the StartActivityExecutionRequest.

bergundy · 2026-04-10T18:13:34Z

+// Implements callback.CompletionSource.
+func (a *Activity) GetNexusCompletion(ctx chasm.Context, _ string) (nexusrpc.CompleteOperationOptions, error) {
+	if !a.LifecycleState(ctx).IsClosed() {
+		return nexusrpc.CompleteOperationOptions{}, serviceerror.NewFailedPrecondition("activity has not completed yet")


This is a bug if it happens.

Suggested change

return nexusrpc.CompleteOperationOptions{}, serviceerror.NewFailedPrecondition("activity has not completed yet")

return nexusrpc.CompleteOperationOptions{}, serviceerror.NewInternal("activity has not completed yet")

bergundy · 2026-04-10T20:39:03Z

+			return serviceerror.NewInvalidArgumentf("unsupported callback variant: %T", variant)
+		}
+
+		id := fmt.Sprintf("%s-%d", requestID, idx)


No need to mention HSM here IMHO.

bergundy · 2026-04-10T20:40:17Z

+	opts := nexusrpc.CompleteOperationOptions{
+		CloseTime: ctx.ExecutionInfo().CloseTime,
+	}
+	if startedTime := attempt.GetStartedTime(); startedTime != nil {


This shouldn't be attempt started time IMHO, it should be the schedule time for the activity.

bergundy · 2026-04-10T20:45:09Z


+// ValidateCallbacks validates completion callbacks: count, URL length, endpoint allowlist, header size, and normalizes
+// header keys to lowercase.
+func ValidateCallbacks(


Don't add more code to the HSM implementation. All new code should go in chasm/lib.

it's been refactored

bergundy · 2026-04-10T20:45:54Z

 	}

+	if cbs := req.GetCompletionCallbacks(); len(cbs) > 0 {
+		if err := callbacks.ValidateCallbacks(


I'd be fine if you switched to service errors. That's very common in the codebase. It's technically redundant because it adds a header with a serialized proto that most SDKs don't care about (only Go SDK does).

bergundy · 2026-04-10T20:59:21Z

+			var failureErr *nexus.FailureError
+			require.ErrorAs(t, completion.Error.Cause, &failureErr)
+			require.Equal(t, defaultFailure.Message, failureErr.Failure.Message)


Use NexusFailureToTemporalFailure and use the SDK's default failure converter to perform assertions on the errors.

bergundy · 2026-04-10T20:59:35Z

+			require.Equal(t, nexus.OperationStateFailed, completion.State)
+			require.False(t, completion.StartTime.IsZero())
+			require.False(t, completion.CloseTime.IsZero())
+			var failureErr *nexus.FailureError


Same as above please.

bergundy · 2026-04-10T20:59:54Z

+			require.Equal(t, nexus.OperationStateCanceled, completion.State)
+			require.False(t, completion.StartTime.IsZero())
+			require.False(t, completion.CloseTime.IsZero())
+			var failureErr *nexus.FailureError


Same here, this should be a canceled error from the Go SDK.

bergundy · 2026-04-10T21:00:22Z

+		case completion := <-ch.requestCh:
+			require.Equal(t, nexus.OperationStateFailed, completion.State)
+			var failureErr *nexus.FailureError
+			require.ErrorAs(t, completion.Error.Cause, &failureErr)


Same here, use Temporal errors for the comparison.

bergundy · 2026-04-10T21:01:21Z

+		require.Equal(t, enumspb.ACTIVITY_EXECUTION_STATUS_TIMED_OUT, descResp.GetInfo().GetStatus())
+	})
+
+	t.Run("ScheduleToCloseTimeoutWithCallbacks", func(t *testing.T) {


No need to check all of the different timeout types, it's all the same outcome.

ok, kept schedule-to-start and added a comment

fretz12 · 2026-04-13T20:42:47Z

 			}

+			if cbs := request.GetCompletionCallbacks(); len(cbs) > 0 {
+				maxCallbacks := h.config.MaxCHASMCallbacksPerExecution(request.GetNamespace())


This uses MaxCHASMCallbacksPerExecution (default 2000) while the frontend Validator uses MaxCallbacksPerWorkflow (default 32). Should standalone activities use their own CHASM-specific limit, or share the same limit as workflows?

Alternatively, we could remove the count check from the Validator entirely since it's a per-component concern that depends on currentCount.
I can use some advice.

It should be the same limit across all archtypes. We have to validate in the CHASM transaction because we don't know how many callbacks are already attached to the execution. The 32 limit is for the HSM implementation that is already deprecated.

bergundy

Still don't see on-conflict-policy and use_existing implemented.

bergundy · 2026-04-13T19:58:16Z

+
+func validatorProvider(dc *dynamicconfig.Collection) *Validator {
+	return NewValidator(
+		dynamicconfig.MaxCHASMCallbacksPerWorkflow.Get(dc),


This DC still says "per workflow"

It now uses callback.maxPerExecution in chasm/lib/callback/config.go

bergundy · 2026-04-13T19:59:31Z

-		"system.maxCallbacksPerExecution",
+	// NOTE (seankane): MaxCHASMCallbacksPerWorkflow is temporary, this will be removed and replaced with MaxCallbacksPerWorkflow
+	// once CHASM is fully enabled
+	MaxCHASMCallbacksPerWorkflow = NewNamespaceIntSetting(


Noted above, the name execution was correct. This is not just for workflows.

You can move this into chasm/lib/callback/config.go AFAIC and rename to callback.maxPerExecution

refactored into chasm/lib/callback/config.go and renamed to callback.maxPerExecution

bergundy · 2026-04-13T23:33:16Z

 			}

+			if cbs := request.GetCompletionCallbacks(); len(cbs) > 0 {
+				maxCallbacks := h.config.MaxCHASMCallbacksPerExecution(request.GetNamespace())


It should be the same limit across all archtypes. We have to validate in the CHASM transaction because we don't know how many callbacks are already attached to the execution. The 32 limit is for the HSM implementation that is already deprecated.

…edtzeng/saa-callbacks

fretz12 · 2026-04-14T18:55:03Z

+// chasm/lib/callback/fx.go and read directly from callback.AllowedAddresses.
+func callbackValidatorProvider(dc *dynamicconfig.Collection) *callback.Validator {
+	return callback.NewValidator(
+		callback.MaxPerExecution.Get(dc),


Previous frontend cb validation basically used the hsm config MaxCallbacksPerWorkflow. want to be extra sure changing this from a default of 32 -> 2000 won't break anything
FYI @bergundy

I think it's fine since the history handler should be validating the total number of attached callbacks anyways. This is just an initial sanity validation step.

But please confirm in the workflow implementation please.

Confirmed:
worfklows

…edtzeng/saa-callbacks

bergundy · 2026-04-14T20:43:12Z

 	return callback.ScheduleStandbyCallbacks(ctx, a.Callbacks)
 }

+type attachCallbacksRequest struct {


I don't think you need this request struct, you can pass in the arguments separately. The single struct is good for if you want to call UpdateComponent with a method directly.

bergundy · 2026-04-14T23:10:49Z

+	cbs := frontendReq.GetCompletionCallbacks()
+	if !result.Created && frontendReq.GetOnConflictOptions().GetAttachCompletionCallbacks() && len(cbs) > 0 {
+		ref := chasm.NewComponentRef[*Activity](result.ExecutionKey)
+		_, _, err := chasm.UpdateComponent(


You shouldn't start a second transaction here. Use chasm.UpdateWithStartExecution instead of StartExecution above.

I tried switching to UpdateWithStartExecution but it breaks for the FAIL conflict policy case. The engine's UpdateWithStartExecution always calls updateFn when the execution already exists — it doesn't check BusinessIDConflictPolicy. So with FAIL policy, instead of getting ExecutionAlreadyStartedError, the updateFn runs successfully and returns Created=false with no error.
To make this work, the engine would need to either respect BusinessIDConflictPolicyFail in the updateFn. Added a TODO for now, we can follow up in separate PR for that

bergundy · 2026-04-14T23:12:39Z

+// chasm/lib/callback/fx.go and read directly from callback.AllowedAddresses.
+func callbackValidatorProvider(dc *dynamicconfig.Collection) *callback.Validator {
+	return callback.NewValidator(
+		callback.MaxPerExecution.Get(dc),


I think it's fine since the history handler should be validating the total number of attached callbacks anyways. This is just an initial sanity validation step.

bergundy · 2026-04-14T23:12:57Z

+// chasm/lib/callback/fx.go and read directly from callback.AllowedAddresses.
+func callbackValidatorProvider(dc *dynamicconfig.Collection) *callback.Validator {
+	return callback.NewValidator(
+		callback.MaxPerExecution.Get(dc),


But please confirm in the workflow implementation please.

bergundy · 2026-04-14T23:14:13Z

+					{Variant: &commonpb.Callback_Nexus_{Nexus: &commonpb.Callback_Nexus{Url: "http://localhost/use-existing-cb"}}},
+				},
+				OnConflictOptions: &commonpb.OnConflictOptions{
+					AttachCompletionCallbacks: true,


You should validate that all 3 attach options are set at once.

It's what we've done for workflow AFAIR. It's a bit silly but we should keep consistent with workflows.

bergundy · 2026-04-14T23:18:17Z

 			require.False(t, resp.GetStarted())
 		})

+		t.Run("AttachesCallbacksToExistingActivity", func(t *testing.T) {


Missing coverage for attaching to a new activity, existing activity and that the second start with on conflict options is idempotent.

bergundy reviewed Apr 2, 2026

View reviewed changes

Comment thread chasm/lib/activity/activity.go Outdated

Comment thread chasm/lib/activity/activity.go

Added callback support for standalone activities

7da34b7

fretz12 force-pushed the fredtzeng/saa-callbacks branch from fc5ff9e to 7da34b7 Compare April 7, 2026 03:18

Added link in StartActivityExecutionResponse

62baad4

fretz12 requested a review from Copilot April 7, 2026 15:54

Copilot started reviewing on behalf of fretz12 April 7, 2026 15:54 View session

Copilot AI reviewed Apr 7, 2026

View reviewed changes

fretz12 added 2 commits April 7, 2026 09:48

Address review issues

868a947

Merge remote-tracking branch 'origin/main' into fredtzeng/saa-callbacks

10ad366

fretz12 marked this pull request as ready for review April 7, 2026 17:06

fretz12 requested review from a team as code owners April 7, 2026 17:06

fretz12 requested review from chaptersix and lina-temporal April 7, 2026 17:06

fretz12 commented Apr 7, 2026

View reviewed changes

fretz12 requested a review from bergundy April 7, 2026 17:12

lina-temporal reviewed Apr 7, 2026

View reviewed changes

dandavison reviewed Apr 9, 2026

View reviewed changes

fretz12 added 2 commits April 10, 2026 08:56

Update to activity callback API

3c2d947

Addressed PR comments

6738984

fretz12 requested review from dandavison and lina-temporal April 10, 2026 17:59

bergundy reviewed Apr 10, 2026

View reviewed changes

fretz12 added 4 commits April 13, 2026 10:47

Addressed PR comments

91efea1

Merge main

e4a93b9

Updated API

2dfefac

Undo file format change

7d3830e

fretz12 requested a review from bergundy April 13, 2026 18:29

fretz12 added 2 commits April 13, 2026 11:30

Fix linter error

15c2692

Change validator to existing allowed addresses config

5d114ed

fretz12 commented Apr 13, 2026

View reviewed changes

fretz12 and others added 2 commits April 13, 2026 16:14

Fixed grpc err message extraction

09b7867

Merge branch 'main' into fredtzeng/saa-callbacks

d493530

bergundy reviewed Apr 13, 2026

View reviewed changes

fretz12 added 2 commits April 14, 2026 11:45

Refactor MaxPerExecution. Add on-conflict attach callbacks support.

85f6c90

Merge remote-tracking branch 'origin/fredtzeng/saa-callbacks' into fr…

53be145

…edtzeng/saa-callbacks

fretz12 commented Apr 14, 2026

View reviewed changes

fretz12 requested a review from bergundy April 14, 2026 18:55

fretz12 and others added 3 commits April 14, 2026 12:07

Merge branch 'main' into fredtzeng/saa-callbacks

41779ee

Register new callback proto package

1520b56

Merge remote-tracking branch 'origin/fredtzeng/saa-callbacks' into fr…

f9d3cf5

…edtzeng/saa-callbacks

bergundy reviewed Apr 14, 2026

View reviewed changes

bergundy changed the title ~~Added callback support for standalone activities~~ Add callback support for standalone activities Apr 15, 2026

Addressed PR comments

7fab7b6

fretz12 requested a review from bergundy April 15, 2026 19:39

	CloseTime: attempt.GetCompleteTime().AsTime(),
	CloseTime: ctx.ExecutionInfo().CloseTime,

	return nexusrpc.CompleteOperationOptions{}, serviceerror.NewFailedPrecondition("activity has not completed yet")
	return nexusrpc.CompleteOperationOptions{}, serviceerror.NewInternal("activity has not completed yet")

Conversation

fretz12 commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed?

Why?

How did you test it?

Uh oh!

bergundy left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dandavison left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bergundy left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

fretz12 commented Apr 2, 2026 •

edited

Loading