[Scheduled Actions V2] state machine protobufs WIP #6901
Conversation
| // Generator is buffering actions. | ||
| SCHEDULER_GENERATOR_STATE_BUFFERING = 2; |
There was a problem hiding this comment.
Based on my review of #6905, you don't need this separate state.
There was a problem hiding this comment.
Agreed, will remove.
| @@ -47,6 +47,47 @@ enum SchedulerState { | |||
| SCHEDULER_STATE_EXECUTING = 2; | |||
| } | |||
|
|
|||
| enum Scheduler2State { | |||
There was a problem hiding this comment.
We don't need ScheduleState anymore. It's part of Tianyu's work that we're replacing.
There was a problem hiding this comment.
Sure, I was planning to remove Tianyu's prototype as part of a later PR; I can send it now and fix this up so we don't have the naming conflict.
| // Executor is awaiting actions to be buffered and eligible for execution. | ||
| SCHEDULER_EXECUTOR_STATE_WAITING = 1; | ||
| // Executor is starting actions. | ||
| SCHEDULER_EXECUTOR_STATE_EXECUTING = 2; | ||
| // Executor is backing off from executing actions. | ||
| SCHEDULER_EXECUTOR_STATE_BACKING_OFF = 3; |
There was a problem hiding this comment.
Why do you need two distinct states for waiting and backing off?
There was a problem hiding this comment.
Yeah, I think they can be removed.
| // Backfiller is awaiting backfill to be requested. | ||
| SCHEDULER_BACKFILLER_STATE_WAITING = 1; | ||
| // Backfiller is actively starting actions. | ||
| SCHEDULER_BACKFILLER_STATE_EXECUTING = 2; | ||
| // Backfiller is backing off from starting actions. | ||
| SCHEDULER_BACKFILLER_STATE_BACKING_OFF = 3; |
| @@ -48,6 +48,9 @@ message BufferedStart { | |||
| temporal.api.enums.v1.ScheduleOverlapPolicy overlap_policy = 3; | |||
| // Trigger-immediately or backfill | |||
| bool manual = 4; | |||
| // An ID generated when the action is buffered for deduplication during | |||
| // execution. Only used by the V2 Scheduler (otherwise left empty). | |||
There was a problem hiding this comment.
Maybe worth calling the scheduler "state machine scheduler" instead of v2?
There was a problem hiding this comment.
Sure, that's probably a more lasting name for it :)
| @@ -155,3 +158,59 @@ message HsmSchedulerState { | |||
| google.protobuf.Timestamp next_invocation_time = 3; | |||
|
|
|||
| } | |||
|
|
|||
| // V2 Scheduler state | |||
| message HsmSchedulerV2State { | |||
There was a problem hiding this comment.
I'd remove Hsm from the name since it's an implementation detail.
There was a problem hiding this comment.
I'd also remove the name State from all of these messages to avoid confusion with the enums that are similarly named.
There was a problem hiding this comment.
Sure, will fix both
| message HsmSchedulerV2State { | ||
| temporal.server.api.enums.v1.Scheduler2State state = 1; | ||
|
|
||
| // scheduler request parameters and metadata. |
There was a problem hiding this comment.
Could you please be consistent in docstrings. It's good practice to capitalize first letters in sentences and use punctuation.
| string schedule_id = 7; | ||
|
|
||
| // Implemented as a sequence number. Useful for substate machines to | ||
| // invalidate transactions based on update requests |
There was a problem hiding this comment.
Not sure I'd say we're invalidating transactions, more like invaliding "work" or task, right? but also used as an optimistic locking mechanism for concurrent update requests.
There was a problem hiding this comment.
It's used for optimistic locking, yeah; I'm trying to give an example of the specific sort of condition that would bump the token in each different struct. If that's confusing, I can simplify the comment.
| // Implemented as a sequence number. Useful for invalidating a stale | ||
| // Generator persisted state write. | ||
| int64 conflict_token = 4; |
There was a problem hiding this comment.
Hmm... can we use the conflict token of the scheduler?
There was a problem hiding this comment.
I'm trying to avoid making an assumption that we can have transactions across multiple columns/documents in CHASM, since I don't think we have that in HSM today (with MachineTransition operating on a single item). If our framework lets me do a transaction across multiple state machines, we could use only the one in the top-level scheduler.
There was a problem hiding this comment.
MachineTransition is a single transition within a transaction on the entire tree. You can rely on that here. CHASM will have similar semantics.
There was a problem hiding this comment.
Got it - will update!
What changed?
Why?
How did you test it?
Potential risks
RequestIdonBufferedStart. As a completely new field the V1 scheduler won't look at, I don't think there's a risk.