fix(server): enforce event stream ownership and diagnostics

[armancharan]

Issue for this PR

Closes #36445

#36445

Parent: #36441

Related: #36311 (minimal Bun SSE disconnect bridge on the event path only — not a platform-wide fix)

✧ raised · ○ in review · ● approved · ✓ merged

#36441 epic: scope streams + bound payloads

Merge in order:
v2
└ ○ #37486 location interest
   └ ○ #37487 session interest + fan-out bench
      └ ○ #37585 stream ownership / diagnostics ← this PR
         └ ○ #37586 reconnect herd

Siblings under the epic (not git parents of the stack tip):
└ ○ #37559 session blobs + payloadHash
└ ○ #37570 ensure-on-first-failure → feeds #37586

Stacked on #37487 (fix/event-subscription-sessions). GitHub base is v2 because the parent branch is fork-only; ownership-only diff: armancharan/opencode@fix/event-subscription-sessions...event-stream-ownership — retarget base onto that branch after #37487 merges (or when the branch exists on anomalyco).

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Guarantees one active event stream per TUI generation, prompt resource release on failure/teardown, and content-free diagnostics for leak detection.

• TUI ownership: monotonic generation + await prior subscribe loop before opening the next; abort request AbortController on every exit; reconnect wait 1000 + random(0..500) ms so N clients do not phase-lock
• Promise SSE: abort signal cancels the body reader (and response.body) so Bun sees client disconnect under custom fetch
• Server: EventFeed.diagnostics() counters (active / opens / closes / serializedEvents / serializedBytes / overflows); debug GET /api/debug/event-feed; IncomingMessage aborted/close → ServerResponse.destroy() so acquireRelease runs (2.0: standalone SSE disconnect can wedge Bun server at 100% CPU #36311 bridge, event path only)

How did you verify your code works?

• packages/server test/event-feed.test.ts — eleven-client churn → baseline; overflow counts; content-free dump
• packages/server test/event-feed-fanout.bench.test.ts — from stack base: fan-out accounting laws (clients × sizes)
• packages/server test/event-feed-ownership.test.ts — scope cancel → baseline; real-socket abort closes body; eleven sequential scopes never accumulate
• packages/tui test/cli/tui/client-ownership.test.tsx — rapid interest ≤1 stream; teardown → 0; prior generation does not receive events after reconnect
• packages/tui test/cli/tui/client-scope.test.tsx — connect / reconnect on change / no-op when unchanged (split)
• typecheck in packages/server, packages/tui, and packages/cli

Acceptance → test

Claim	Test
One mounted TUI → one stream; zero after teardown	teardown leaves zero active event streams + rapid interest changes never exceed one active event stream
Reconnect churn never exceeds one stream per TUI	rapid interest changes never exceed one active event stream
Eleven clients → eleven streams (no accumulation)	returns active subscriber count to baseline when scopes close after eleven-client churn + eleven sequential subscribe scopes never accumulate active subscribers
Cancel real network client → response closed, baseline	canceling a subscriber scope… + aborting a real Node HTTP client returns EventFeed.active to baseline
Prior generation does not receive events after interest reconnect	event IDs from a prior generation are not delivered after interest reconnect
Diagnostics expose leaks without payloads	returns active… dump asserts + overflow counters

Screenshots / recordings

N/A — not a UI layout change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, the PRs found are all explicitly mentioned as related work in PR #37585's description (parent stack and sibling work under #36441). These are not duplicates but intentionally related:

• feat(server): opt-in location interest for event subscriptions #37486 - Parent: location interest (earlier in stack)
• feat(server): narrow event subscriptions by session interest #37487 - Parent: session interest (immediate parent, this PR is stacked on it)
• feat(core): bound tool and admitted event payloads via session blobs #37559 - Sibling: bound payloads (under same issue 2.0: Scope event streams and bound event payloads #36441)
• test(cli): lock managed reconnect ensure-on-first-failure #37570 - Sibling: ensure-on-first-failure (under same issue 2.0: Scope event streams and bound event payloads #36441)

No duplicate PRs found