Background
Split out of the thread-scoped ACP sessions PR (#6732) review (reviewer P1).
Not introduced by that PR — it is a pre-existing lifecycle-hardening concern
that thread scoping makes more visible because it multiplies the number of
live sessions (one per thread instead of one per channel).
Problem
Sessions are retained indefinitely:
- The pool's per-scope maps in
buzz-acp (sessions, turn_counts,
core_sections, canvas_sections, deliveries, session_owners) have no
time- or size-based eviction. They only shrink on explicit triggers
(!rotate, channel/membership removal, agent exit/panic). Under thread
policy a busy channel can accumulate one entry set per thread and never
release them.
buzz-agent sessions can retain their McpRegistry resources. A finite
BUZZ_AGENT_MAX_SESSIONS exists but defaults to unlimited.
- ACP has no obvious per-session close contract, so deleting only the
Buzz-side session IDs would not reliably release provider-side resources
(subprocesses, MCP servers, model context).
Why it isn't a clean PR-local fix
A partial eviction (dropping Buzz-side IDs) would leak provider resources
and give a false sense of boundedness. This needs a designed lifecycle:
- an idle-TTL and/or LRU cap on pool scope maps, keyed by
SessionScope,
- a real per-session close/teardown contract that releases provider resources
(ACP session close, McpRegistry teardown),
- a sensible finite default for
BUZZ_AGENT_MAX_SESSIONS,
- metrics/telemetry for live-session count and evictions.
Acceptance (proposal)
- Bounded live sessions per agent under sustained multi-thread load.
- Evicting a session provably releases provider-side resources.
- Defaults are safe for the default
channel policy (no behavior change) and
bound growth under thread policy.
References
Background
Split out of the thread-scoped ACP sessions PR (#6732) review (reviewer P1).
Not introduced by that PR — it is a pre-existing lifecycle-hardening concern
that thread scoping makes more visible because it multiplies the number of
live sessions (one per thread instead of one per channel).
Problem
Sessions are retained indefinitely:
buzz-acp(sessions,turn_counts,core_sections,canvas_sections,deliveries,session_owners) have notime- or size-based eviction. They only shrink on explicit triggers
(
!rotate, channel/membership removal, agent exit/panic). Under threadpolicy a busy channel can accumulate one entry set per thread and never
release them.
buzz-agentsessions can retain theirMcpRegistryresources. A finiteBUZZ_AGENT_MAX_SESSIONSexists but defaults to unlimited.Buzz-side session IDs would not reliably release provider-side resources
(subprocesses, MCP servers, model context).
Why it isn't a clean PR-local fix
A partial eviction (dropping Buzz-side IDs) would leak provider resources
and give a false sense of boundedness. This needs a designed lifecycle:
SessionScope,(ACP session close,
McpRegistryteardown),BUZZ_AGENT_MAX_SESSIONS,Acceptance (proposal)
channelpolicy (no behavior change) andbound growth under
threadpolicy.References
crates/buzz-acp/src/pool.rs(scope maps,invalidate_*)buzz-agentMcpRegistry,BUZZ_AGENT_MAX_SESSIONS