Repository navigation
Conversation
THardy98
force-pushed
the
dev/sticky-activities
branch
3 times, most recently
from
October 21, 2026 14:02
919da29 to
3f4b21b
Compare
THardy98
force-pushed
the
dev/sticky-activities
branch
5 times, most recently
from
October 22, 2026 01:38
07fd242 to
5b870cc
Compare
THardy98
force-pushed
the
dev/sticky-activities
branch
from
October 28, 2026 20:58
0234cfc to
b6d76ef
Compare
Pin Core to the session stack (temporalio/sdk-rust#1687 at 6e88cb53), which adopts the session API from temporalio/api#885, regenerate the Python protos, refresh the bridge lockfile, and import Core's release notes.
`Worker(session_config=WorkerSessionConfig(...))` lets a worker serve sessions (it also polls its sticky queue for activities). `SingleSessionAdmission(stable_identity=...)` dedicates the worker to one workflow for its lifetime; Core then polls only its sticky queues and excludes it from eager workflow start. Session workers need fixed-size activity slots: two for paired polling, one for single-session.
Activities started inside `workflow.activity_session(ActivitySessionOptions(placement=UseWorkflowSession()))` that target the workflow's task queue run on the workflow's worker; others use ordinary routing. The scope is a ContextVar read in the caller's task: it nests, follows tasks created inside it, and doesn't reach signal or update handlers unless they open their own scope. The resolved options are on `StartActivityInput.session_options` for interceptors. Core validates placement (session worker, workflow's task queue), including during replay, so Python only resolves the scope into the command. `ActivitySessionOptions`, `ActivitySessionPlacement` and `UseWorkflowSession` live in temporalio.common.
Session workflows only run, including replay, on workers that serve sessions; replaying elsewhere would silently drop the affinity their activities expect, so Core fails the workflow task. The Replayer accepts the same `session_config` as `Worker` and passes it to Core's replay worker. Core requires remote activities alongside session options; the replay worker still runs workflow-only, and `admission` has no effect since it doesn't poll.
THardy98
force-pushed
the
dev/sticky-activities
branch
from
October 28, 2026 21:08
b6d76ef to
ffb0b6b
Compare
Cover scope resolution (nesting, explicit and other task queues, tasks created in a scope, scoped and unscoped signal handlers), Core rejecting a session activity on a non-session worker, `activity_session` outside a workflow, and the Core-enforced worker rules: nonzero workflow cache, non-empty stable identity, and no eager workflow start for single-session workers. These run against the stock test server.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was changed
This change introduces a minimal subset of the planned Sessions API as specified in temporalio/api#885 (commit
d183f54c642fe320218bc3bf8592b2533540f050).The intention with the Sessions API is to address worker affinity use cases.
Changes:
The current API supports:
worker options to enable a worker to serve sessions:
Worker(session_config=WorkerSessionConfig(...))worker session options include a "single session" mode that allows it to serve only a single session
SingleSessionAdmission(stable_identity=...)the stable identity lets the session bind to a particular identity (i.e. in the event the worker dies and a new worker with the same stable identity is provided).
activity session options that allow an activity to run in the same session as its workflow:
workflow.activity_session(ActivitySessionOptions(placement=UseWorkflowSession()))this co-locates a workflow's workflow and activity tasks on the same worker.
Note: the activity must run on the same task queue as the workflow (otherwise, it will be routed to its own task queue)
Replayer allows Session workflows to replay only on session-enabled workers
Usage:
The API uses a context manager to declare session scope, example usage:
Note
This PR is dependent on feature branches (PRs):
6e88cb53)Why?
An initial Python API for the Sessions API (activity affinity and single-session workers), to serve worker affinity use cases.