Skip to content

[Scheduler] Skip recomputing FutureActionTimes after handling completion events#10896

Draft
lina-temporal wants to merge 1 commit into
mainfrom
sched-visi-futureactiontimes
Draft

[Scheduler] Skip recomputing FutureActionTimes after handling completion events#10896
lina-temporal wants to merge 1 commit into
mainfrom
sched-visi-futureactiontimes

Conversation

@lina-temporal

@lina-temporal lina-temporal commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

Pending a functional test to show observed visibility write count

What changed?

We skip computing FutureActionTimes in GeneratorTask as a result of handling completion callbacks.

Why?

The completion handler runs a GeneratorTask to drive the idle timer, which is reset on external events (including completions). Whenever a task runs, CHASM framework calls Memo to determine if it should make a visibility upsert. Prior to the change, we'd observe a Memo write from the completion handler GeneratorTask removing an entry (because RemainingActions decrements, for example). Then, when the looping GeneratorTask that drives automated actions ran, it caused an oscillation from adding another entry (because now the high water mark has advanced past the start interval).

The write that merely removes an entry before the high water mark moves past the scheduled interval isn't particularly useful to anyone, so it's wasted load on visi. This change removes the potential for a completion callback to trigger a visibility memo write.

Oh, note: I did also experiment with trying to get fancy within GeneratorTask, in deciding if it should update FutureActionTimes automatically, but I couldn't come up with a clean, pure condition that didn't also regress some weird edge case test.

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)

Potential risks

  • Biggest risk is that we somehow don't update visibility's FutureActionTimes field when we expected to. However, this is mitigated given that the regularly-scheduled GeneratorTask always recomputes future action times, so in a scenario where I've missed a valid case for updating visi as a result of a completion, the worst case is visi updates only after the next interval elapses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant