[Shivs11]

What changed?

Adds initial server support for keeping one AgentCore session dedicated to one workflow execution. Builds on #12630.

A starts on shared queue foo → session S acquires A
Later work for A             → sticky queue S
Replacement worker using S   → A's next tasks

• Workflow tasks and activities that request the workflow's session use the sticky queue named by the stable identity. Activities do not join the session automatically and are opt-in right now using activity session options!
• The assignment survives queue reload, so a replacement worker using the same stable identity can receive the original workflow's tasks. Assigned workflow queue records are kept after workflow completion to prevent reuse.

Why?

An AgentCore run needs to keep its own session even when its worker stops and is later replaced. Spare worker capacity should not cause that session to pick up another run.

How did you test it?

• added four new server tests in tests/single_session_taskpoller_test.go and then ran the existing suites.

Pending work and limits

This is an initial happy-path POC for review. The following needs more pondering upon honestly:

• Versioning and AU workflows: : do not have tests for this; however, pinned workflows with sessions works.
• Uncertain acquisition outcomes: for example --> History may start A without Matching learning that it succeeded; a later poll could then acquire B for the same S. Isolation in these cases is not guaranteed by this POC.
• Queue name collisions: this POC assumes session queue names are not also used as normal queue names. The server does not reserve those names or validate the workflow owner of every task sent directly to S.
• Later scope: Continue-As-New, child workflows, and starting/stopping AgentCore compute.

Suggested review order

This PR is stacked on #12630.

1. Saved assignment: persistence proto fields, db.go, and queue-record retention.
2. History binding: RecordWorkflowTaskStarted, mutable-state sticky setters/reset paths, completion/failure/timeouts, and task routing.
3. Matching: acquisition coordination in task_queue_partition_manager.go; direct initial polling and assignment methods in physical_task_queue_manager.go; the shared request builder in pri_forwarder.go; and assignment persistence in db.go. An empty forwarding source lets the Matching client choose a normal read partition, while the generated client copy preserves session options. Ordinary sticky forwarding remains unchanged. The shared backlog callback still preserves notices received during queue initialization.
4. Tests: the corresponding owner test files, then tests/single_session_taskpoller_test.go. Read generated files last.

[Shivs11]

just something that i observed an agent do :)

[Shivs11]

the main change that i have added over here is that i have allowed sessionOptions to be sendable on matching poll RPC's for the sole purpose of being able to send the first sticky session poll to a normal task queue partition (and use matching's load balancing)

[Shivs11]

this can be debatable but the main reason why this has been added is because now, for session based s2s timeouts, we want to not clear stickiness and just place the task back on the sticky task queue. Earlier, for non session based tasks, we were clearing the stickiness of these tasks and then having transient tasks being picked up from the normal task queue without any s2s timeouts. That changes here imo

[ShahabT]

Reviewed all history side and half of matching side. Thanks for the great work, and sorry for the big list of comments! this is a big change, hence these is much to comment :)