[Scheduled Actions] CHASM scheduled actions visibility support #8292

lina-temporal · 2025-09-05T22:42:36Z

What changed?

Visibility writes are added to the Scheduler components.

How did you test it?

bergundy · 2025-09-08T23:45:52Z

chasm/lib/scheduler/scheduler.go

+	customSearchAttributes *commonpb.SearchAttributes,
+) error {
+	needsTask := false // Set to true if we need to write anything to Visibility.
+	visibility, err := s.Visibility.Get(ctx)


Not related to this PR but are we ever expecting an error getting a component to be an error that the application needs to handle? What reasons would be for this failure? Can we just make the method panic instead?

When we support partial read in the future, there could be some transient error returned here. For now, it will only be serialization errors.

If it's a transient, unexpected error, it should be okay to panic IMHO. That would be better than complicating the user interface. There's never really a way for a developer to react to this situation.

bergundy · 2025-09-08T23:47:08Z

chasm/lib/scheduler/scheduler.go

+	if customSearchAttributes != nil &&
+		len(customSearchAttributes.GetIndexedFields()) > 0 {


nit: This is enough because proto getters work with nils.

Suggested change

if customSearchAttributes != nil &&

len(customSearchAttributes.GetIndexedFields()) > 0 {

if len(customSearchAttributes.GetIndexedFields()) > 0 {

bergundy · 2025-09-08T23:48:16Z

chasm/lib/scheduler/scheduler.go

+	}
+
+	// Update Paused status.
+	var currentPaused bool


This is exactly why I didn't want components to use imperative logic to update their search attributes. This logic should be part of the framework.

If we can afford it timeline-wise I'd much prefer if we coded up a better abstraction in the framework.

In general I agree. Also acknowledging that imperative logic means component author needs to remember update those attributes.

We discussed about the field tag approach which addresses this concern and also the SA registration problem but decided to do that as a follow up to unblock the Scheduler migration and deliver value sooner. It's more of a ROI & priority discussion for the entire OSS team.

bergundy · 2025-09-09T00:04:34Z

chasm/lib/scheduler/scheduler.go

+
+	// Update visibility if the memo is out-of-date or absent.
+	if currentInfoPayload == nil ||
+		!bytes.Equal(currentInfoPayload.Data, newInfoPayload) {


Proto marshal is not deterministic by default, this comparison will give you false negatives. You will want to unmarshal and use proto.Equal instead.

Another reason why component authors shouldn't implement all of this logic.

bergundy · 2025-09-09T00:05:57Z

chasm/lib/scheduler/scheduler.go

+// attributes will be left as-is with it unset.
+//
+// See mergeCustomSearchAttributes for how custom search attributes are merged.
+func (s *Scheduler) UpdateVisibility(


I don't like this approach, it assumes that the component author will remember to update visibility anytime that an attribute changes. This should be the framework's responsibility and should be done automatically when a transaction is closed.

bergundy · 2025-09-09T00:08:31Z

chasm/lib/scheduler/util.go

+	for key, newPayload := range customAttrs {
+		oldPayload, alreadySet := currentAttrs[key]
+
+		if !alreadySet || !bytes.Equal(oldPayload.Data, newPayload.Data) {


As mentioned before, you cannot rely on byte equality for this comparison.

yycptt · 2025-09-09T20:58:26Z

chasm/lib/scheduler/scheduler.go

+	if needsTask {
+		visibility.GenerateTask(ctx)
+	}


This is unnecessary, Visibility component automatically generates a task when it's updated.

yycptt · 2025-09-09T21:00:52Z

chasm/lib/scheduler/scheduler.go

+	customSearchAttributes *commonpb.SearchAttributes,
+) error {
+	needsTask := false // Set to true if we need to write anything to Visibility.
+	visibility, err := s.Visibility.Get(ctx)


When we support partial read in the future, there could be some transient error returned here. For now, it will only be serialization errors.

yycptt · 2025-09-09T21:13:56Z

chasm/lib/scheduler/scheduler.go

+	if !ok || currentPaused != s.Schedule.State.Paused {
+		upsertAttrs[searchattribute.TemporalSchedulePaused] = s.Schedule.State.Paused
+	}


This is more like a "refresh visibility" approach. Do we have a like PauseSchedule method where we can update the field?

yycptt · 2025-09-09T21:22:07Z

chasm/lib/scheduler/scheduler.go

+	currentMemo, err := visibility.GetMemo(ctx)
+	if err != nil {
+		return err
+	}
+	currentInfoPayload := currentMemo[visibilityMemoFieldInfo]


nit: can use the generic chasm.GetMemo() function which returns a strongly typed value instead of Payload

yycptt · 2025-09-09T21:24:15Z

chasm/lib/scheduler/scheduler.go

+		newMemo := map[string]any{visibilityMemoFieldInfo: newInfoPayload}
+		err = visibility.UpsertMemo(ctx, newMemo)


UpsertMemo will perform the encoding to Payload type, should just use newInfo here.

yycptt · 2025-09-09T21:26:37Z

chasm/lib/scheduler/scheduler.go

+	currentPausedPayload, ok := currentAttrs[searchattribute.TemporalSchedulePaused]
+	if ok {
+		err = payload.Decode(currentPausedPayload, &currentPaused)
+		if err != nil {
+			return err
+		}
+	}


nit: can use the generic chasm.GetSearchAttribute() method here as well and you don't need to do the decoding.

yycptt · 2025-09-09T21:30:06Z

chasm/lib/scheduler/util.go

+			// Key isn't in the new map, delete it.
+			upsertAttrs[key] = nil


Will this work? At least when I was coding the visibility.UpsertSearchAttributes() method I wasn't thinking of using that as a way for deletion.

This is how it worked in the SDKs before we had typed search attributes.

yycptt · 2025-09-09T21:38:37Z

chasm/lib/scheduler/scheduler.go

+	}
+
+	// Update Paused status.
+	var currentPaused bool


In general I agree. Also acknowledging that imperative logic means component author needs to remember update those attributes.

We discussed about the field tag approach which addresses this concern and also the SA registration problem but decided to do that as a follow up to unblock the Scheduler migration and deliver value sooner. It's more of a ROI & priority discussion for the entire OSS team.

bergundy

Based on @yycptt's comments the abstraction isn't too bad today.
Seems like you don't need to manually generate a task, serialize and deserialize payloads, etc...

If we could also eliminate the need to compare search attributes and do incremental updates only to fields that changed, that would be good enough for me for merging this PR and deferring the declarative APIs for later.

Ideally we wouldn't even need to do that, if you could just recompute the desired visibility state and have the visibility component understand what needs to be updated (if anything at all) that would be much much better than what we have today.
Is that doable?

bergundy · 2025-09-09T22:32:29Z

chasm/lib/scheduler/scheduler.go

+	customSearchAttributes *commonpb.SearchAttributes,
+) error {
+	needsTask := false // Set to true if we need to write anything to Visibility.
+	visibility, err := s.Visibility.Get(ctx)


If it's a transient, unexpected error, it should be okay to panic IMHO. That would be better than complicating the user interface. There's never really a way for a developer to react to this situation.

bergundy · 2025-09-09T22:34:50Z

chasm/lib/scheduler/util.go

+			// Key isn't in the new map, delete it.
+			upsertAttrs[key] = nil


This is how it worked in the SDKs before we had typed search attributes.

[Scheduled Actions] CHASM scheduled actions visibility support

563f68c

lina-temporal requested review from bergundy and yycptt September 5, 2025 22:42

lina-temporal requested a review from a team as a code owner September 5, 2025 22:42

bergundy reviewed Sep 9, 2025

View reviewed changes

yycptt reviewed Sep 9, 2025

View reviewed changes

bergundy reviewed Sep 9, 2025

View reviewed changes

		if customSearchAttributes != nil &&
		len(customSearchAttributes.GetIndexedFields()) > 0 {

	if customSearchAttributes != nil &&
	len(customSearchAttributes.GetIndexedFields()) > 0 {
	if len(customSearchAttributes.GetIndexedFields()) > 0 {

		newMemo := map[string]any{visibilityMemoFieldInfo: newInfoPayload}
		err = visibility.UpsertMemo(ctx, newMemo)

		// Key isn't in the new map, delete it.
		upsertAttrs[key] = nil

[Scheduled Actions] CHASM scheduled actions visibility support #8292

Are you sure you want to change the base?

[Scheduled Actions] CHASM scheduled actions visibility support #8292

Uh oh!

Conversation

lina-temporal commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed?

How did you test it?

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!

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!

Uh oh!

lina-temporal commented Sep 5, 2025 •

edited

Loading