Repository navigation
Conversation
Rename WorkerSessionOptions' oneof to admission, document single-session binding semantics, and model activity placement as a oneof with an Empty workflow_session member in place of bool use_workflow_session. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Shivs11
left a comment
There was a problem hiding this comment.
gonna approve this, but just one comment that might need ur attention
| // 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 |
There was a problem hiding this comment.
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.
Yeah that's interesting, I'm not sure how that'd work on the matching side.
We're treating the stable_identity effectively as a configurable sticky queue, in which case, I suppose you'd have 2 pollers so tasks are first-come-first-serve.
| google.protobuf.Empty workflow_session = 1; | ||
|
|
||
| // later session_id, etc | ||
| // Future: string stable_identity = 2; (target a named worker) |
There was a problem hiding this comment.
I can see a world where if we do have string stable_identity introduced, a user could get confused between ActivitySessionOptions.placement.stable_identity vs the stableIdentity that they have defined in SingleSessionOptions.stable_identity
as in, could a user think -- "i have defined SingleSessionOptions.stable_identity = acs-1", should i set workflow_session or should i set stable_identity = acs-1"?
There was a problem hiding this comment.
Yeah - definitely open to renaming it if it's confusing.
Just a comment so very open to changing in the future
What changed?
Basically just a single field change and some comment changes based on a Notion doc proposal.
Why?
Breaking changes
Server PR