Repository navigation
Propose basic session API shape #893
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: sticky-activity-session-options
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,36 +9,45 @@ option java_outer_classname = "MessageProto"; | |
| option ruby_package = "Temporalio::Api::Session::V1"; | ||
| option csharp_namespace = "Temporalio.Api.Session.V1"; | ||
|
|
||
| import "google/protobuf/empty.proto"; | ||
|
|
||
| // EXPERIMENTAL. Subject to redesign or removal. | ||
| // Configures a worker's polling for sessions that keep workflow and activity | ||
| // tasks on a stable worker destination. Activities opt into session routing | ||
| // through ActivitySessionOptions on their scheduling commands. | ||
| // Sent on workflow and activity polls. Presence means this worker can serve | ||
| // sessions, where the current implementation of sessions = sticky activities. | ||
| message WorkerSessionOptions { | ||
| oneof isolation { | ||
| // Admission control, if unset the worker accepts an arbitrary number of | ||
| // sessions (bounded by session slots in the future) | ||
| oneof admission { | ||
| // The expectation is that this is set for the AgentCore use case. | ||
| // SDK-side, if this is specified, the worker *only* sticky polls. | ||
| SingleSessionOptions single_session = 1; | ||
| } | ||
| } | ||
|
|
||
| // EXPERIMENTAL. Subject to redesign or removal. | ||
| // Dedicates a sticky destination to the first workflow matched to it. | ||
| // Workflow sticky polls may be forwarded to the normal queue until the first | ||
| // workflow task is dispatched. The server persists that workflow ID and does | ||
| // not forward subsequent polls, including after workflow completion. | ||
| // Activity sticky polls are never forwarded to the normal queue. | ||
| // Serve exactly one workflow for the worker's lifetime, including across | ||
| // process restarts with the same stable_identity. The server binds the worker | ||
| // to the first workflow task it hands out, and dispatches no other work here, | ||
| // even after that workflow completes. | ||
| message SingleSessionOptions { | ||
| // Stable sticky task queue name, shared by workflow and activity polls. | ||
| // Reuse this value across worker restarts within the same session, but not | ||
| // across concurrently running workers. This is distinct from worker identity. | ||
| // The SDK must also set the polled sticky task queue's name to this value. | ||
| // Identity the binding is stored under. Reuse it across restarts of the | ||
| // same session, not across concurrently running workers. | ||
| // | ||
| // Note: this effectively acts as a configurable sticky queue. | ||
| // Note: we are currently unsure how this will evolve. May be deprecated as | ||
| // the session model develops. | ||
| string stable_identity = 1; | ||
| } | ||
|
|
||
| // EXPERIMENTAL. Subject to redesign or removal. | ||
| // Resolved activity placement. Unset = normal task-queue routing. | ||
| // workflow_session requires the activity's task queue to be the workflow's, | ||
| // and the workflow's worker to serve sessions. | ||
| message ActivitySessionOptions { | ||
| oneof session { | ||
| // Execute this activity as part of its workflow's session. | ||
| // Currently routes to the workflow's sticky task queue when true. | ||
| bool use_workflow_session = 1; | ||
| oneof placement { | ||
| // Run on the workflow's current worker (its sticky queue). | ||
| google.protobuf.Empty workflow_session = 1; | ||
|
|
||
| // later session_id, etc | ||
| // Future: string stable_identity = 2; (target a named worker) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can see a world where if we do have as in, could a user think -- "i have defined
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah - definitely open to renaming it if it's confusing. |
||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a thought -- maybe a server question but what if someone were to use this and have two worker instances have the same stable_identity? I guess we have documented not to do this since if this does happen, they don't have worker level affinity in that world.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's interesting, I'm not sure how that'd work on the matching side.
We're treating the
stable_identityeffectively as a configurable sticky queue, in which case, I suppose you'd have 2 pollers so tasks are first-come-first-serve.