fix: harden SSE replay and backpressure handling

[AndresCdo]

Issue for this PR

Closes #19584

Type of change

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

What does this PR do?

This fixes reliability gaps in the /event SSE route.

• Adds explicit control events for client recovery:
  • server.stream.expired when replay (after_seq) cannot be satisfied.
  • server.stream.lagged when live subscribers fall behind and overflow the queue.
• Splits replay and live paths in /event so replay responses are deterministic and terminal.
• Adds bounded queue behavior to AsyncQueue (max, force, clear, size) and uses it in live event streaming.
• Adds OPENCODE_EXPERIMENTAL_EVENT_QUEUE_MAX to tune queue cap.
• Adds focused server tests for replay-valid, replay-expired, malformed cursor, tiny-queue replay invariant, and overflow signaling.

Why this works: replay responses are emitted directly and are not dropped by backpressure handling, while live streaming now has bounded memory and explicit lag signals.

How did you verify your code works?

From packages/opencode:

• bun typecheck (run twice)
• bun test test/server/event-subscribe.test.ts (run twice)
• bun test test/server (run twice)
• OPENCODE_EXPERIMENTAL_EVENT_QUEUE_MAX=1 bun test test/server/event-subscribe.test.ts

Local binary validation:

• bun run build --single --skip-install --skip-embed-web-ui
• smoke tested built binary with --version and --help

Screenshots / recordings

N/A (server-side behavior 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:

Potential Duplicate PRs Found

PR #19493 - "fix: add SSE backpressure safeguards for slow clients"

• fix: add SSE backpressure safeguards for slow clients #19493
• Why related: Directly addresses SSE backpressure handling, which overlaps with the bounded queue semantics and backpressure-safe live path in PR fix: harden SSE replay and backpressure handling #19583.

PR #19423 - "fix(server): add backpressure to SSE event queues"

• fix(server): add backpressure to SSE event queues #19423
• Why related: Explicitly adds backpressure to SSE event queues, core to the queue overflow handling (server.stream.lagged) in PR fix: harden SSE replay and backpressure handling #19583.

Both PRs #19493 and #19423 appear to be addressing SSE backpressure issues that overlap with the current PR's scope. Recommend checking if these are related work or if they should be consolidated.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[AndresCdo]

Follow-up on duplicate detection:

I reviewed #19493 and #19423.

Overlap:

• All three PRs target SSE resilience/backpressure around /event.

What this PR adds beyond queue backpressure:

• Explicit replay contract for after_seq requests.
• Explicit machine-readable terminal events:
  • server.stream.expired for unsatisfied replay cursors.
  • server.stream.lagged for live overflow.
• Replay/live path separation so replay responses are deterministic and not dropped under live pressure.
• Tests covering replay-valid/replay-expired/malformed-cursor/tiny-queue invariants.

Policy updates completed:

• Opened issue Bug: /event replay semantics are implicit and conflict with SSE backpressure handling #19584.
• Linked it in PR body with Closes #19584.

If maintainers want consolidation, I can retarget this as a follow-up onto the active backpressure PR branch.

[AndresCdo]

Quick status update from my side:

• I kept this PR intentionally scoped to SSE replay/backpressure hardening only.
• While waiting for review, I continued follow-up work in a stacked fork branch (not added to this PR), so this one remains small and easy to evaluate.
• If you prefer consolidation with other SSE efforts, I can rebase/cherry-pick into the target branch you prefer.

Would appreciate guidance when you have a moment.

@Hona @adamdotdevin

[Hona]

you are literally a bot

[AndresCdo]

you are literally a bot

Let me explein to you @Hona what I'm trying to do: I need to create agents team and concurrency is a problem. This create a fundamental fix to next steps. An sorry if this look like a bot, I just using Opencode to fix opencode.