Standalone activities to support for ID conflict use existing

[fretz12]

What changed?

Added support for ID conflict use existing. Added error details on conflict policy fail.

Why?

We now have the use existing policy support on chasm engine, so we can support it. Also need to pass back error details on conflict policy fail in struct ActivityExecutionAlreadyStartedError

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)

---

Note

^{Cursor Bugbot is generating a summary for commit f264bba. Configure here.}

[fretz12]

cursor review

[cursor]

Bug: UseExisting policy returns incorrect Started=true for existing activity

When ACTIVITY_ID_CONFLICT_POLICY_USE_EXISTING is used and an activity with the same ID already exists, the response incorrectly returns Started: true. The callback that creates the response with Started: true is always executed, even when the engine returns an existing activity via the UseExisting conflict policy. Per the established convention (seen in workflow's similar USE_EXISTING behavior in telemetry tests), Started should be false when returning an existing execution rather than creating a new one. This could mislead callers into thinking a new activity was started when it wasn't.

chasm/lib/activity/handler.go#L68-L84

temporal/chasm/lib/activity/handler.go

Lines 68 to 84 in 76033ba

	},
	func(mutableContext chasm.MutableContext, request *workflowservice.StartActivityExecutionRequest) (*Activity, *workflowservice.StartActivityExecutionResponse, error) {
	newActivity, err := NewStandaloneActivity(mutableContext, request)
	if err != nil {
	return nil, nil, err
	}
	err = TransitionScheduled.Apply(newActivity, mutableContext, nil)
	if err != nil {
	return nil, nil, err
	}
	return newActivity, &workflowservice.StartActivityExecutionResponse{
	Started: true,
	// EagerTask: TODO when supported, need to call the same code that would handle the HandleStarted API
	}, nil
	},

 

---

[fretz12]

Bug: UseExisting policy returns incorrect Started=true for existing activity

When ACTIVITY_ID_CONFLICT_POLICY_USE_EXISTING is used and an activity with the same ID already exists, the response incorrectly returns Started: true. The callback that creates the response with Started: true is always executed, even when the engine returns an existing activity via the UseExisting conflict policy. Per the established convention (seen in workflow's similar USE_EXISTING behavior in telemetry tests), Started should be false when returning an existing execution rather than creating a new one. This could mislead callers into thinking a new activity was started when it wasn't.

chasm/lib/activity/handler.go#L68-L84

temporal/chasm/lib/activity/handler.go

Lines 68 to 84 in 76033ba

	},
	func(mutableContext chasm.MutableContext, request *workflowservice.StartActivityExecutionRequest) (*Activity, *workflowservice.StartActivityExecutionResponse, error) {
	newActivity, err := NewStandaloneActivity(mutableContext, request)
	if err != nil {
	return nil, nil, err
	}
	err = TransitionScheduled.Apply(newActivity, mutableContext, nil)
	if err != nil {
	return nil, nil, err
	}
	return newActivity, &workflowservice.StartActivityExecutionResponse{
	Started: true,
	// EagerTask: TODO when supported, need to call the same code that would handle the HandleStarted API
	}, nil
	},

 

That behavior would seem confusing as the activity is in Started state. WHere are you deducing this for workflows? Give me evidence

[dandavison]

I think we should check that the returned runID is the same as the first one, and that started is false.

[fretz12]

Added runID assertion.
As discussed, added a TODO. We need a way for chasm engine to tell us execution is already created. I'll dig through the code and ping chasm crew

[dandavison]

Approved with that suggestion to change the error and some minor comments.