Remove the process-local workflow session registration token

[TsuyoshiUshio]

Please provide us with the following information:

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [x] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

1. Inspect src/azure_functions_agents/workflows/context.py.
2. Observe that WorkflowSessionContext.token is generated by register_workflow_session() and used only by unregister_workflow_session() to avoid an older request deleting a newer entry from the process-local _registry.
3. Inspect the current production path in workflows/tools.py and runner.py. Workflow tools receive a request-local WorkflowSessionContext constructed directly from the owner slug, session ID, agent name, and Durable client. This context uses token="" and does not look up the registry.
4. Observe that no production caller under src/ invokes register_workflow_session() or get_workflow_session().

Any log messages given by the failure

N/A. This is design debt rather than a runtime failure.

Expected/desired behavior

Remove WorkflowSessionContext.token and the unused process-local workflow session registry APIs (register_workflow_session, unregister_workflow_session, and get_workflow_session) if compatibility analysis confirms they are not part of a supported public surface.

WorkflowSessionContext should represent only data required by workflow operations, such as owner slug, session ID, agent name, and the Durable client. Workflow status, cancellation, and termination must continue to use the Durable workflow instance ID plus owner/session authorization; they must not depend on process-local state.

If the registry must temporarily remain for compatibility, move it behind a private compatibility boundary and rename token to registration_token so it cannot be mistaken for a persisted workflow credential or cancellation token. Explicitly document that it is worker-local and disappears on restart.

OS and Version?

All supported platforms and Azure Functions hosting environments.

Versions

Current main / per-agent Dynamic Workflows implementation.

Mention any other details that might be useful

The token is not an authentication token, Durable workflow token, or persisted session identifier. It is only a generation marker for concurrency-safe cleanup of an in-memory dictionary:

_registry: dict[tuple[str, str], WorkflowSessionContext] = {}

Example of the race it originally guarded against: request A registers token A; request B overwrites the same registry slot with token B; request A then finishes and must not remove request B's context.

The current request-local production design makes that registry unnecessary. Azure worker crashes and scale-out do not require the token: Durable orchestration state is persisted by Azure Storage or Durable Task Scheduler, while cancellation and termination address the persisted orchestration by instance ID.

Suggested acceptance criteria:

• Remove the registry and token from production workflow context, or isolate and clearly name them as compatibility-only behavior.
• Preserve workflow start, status, list, cancel, and terminate behavior after a worker restart.
• Preserve owner/session isolation checks based on the workflow instance ID.
• Update or remove registry-specific tests.
• Add a restart-oriented test proving cancellation does not depend on process-local state.
• Update architecture/API documentation if any exported compatibility surface changes.

This may be a breaking change if the registry helpers are intentionally public, so their export and downstream usage should be checked before removal.

---

Thanks! We'll be in touch soon.