Skip to content

buzz-acp: bound ACP session + provider-resource lifecycle (no eviction today) #6958

Description

@salman1993

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions