Conversation
|
Warning Review limit reached
Next review available in: 56 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The Streamable HTTP transport has telemetry for transport
init/connect/disconnect/terminate but no signal for the moment a client
(re)attaches an SSE handler to a session. That reconnect point is exactly
where hosts need a hook -- e.g. to observe standalone GET/SSE stream
churn, or to react when a client reconnects after a zero-handler gap.
Emit `[:anubis_mcp, :transport, :sse_handler, :registered]` from the
`{:register_sse_handler, ...}` handler after the handler is monitored and
recorded. Metadata: %{transport, server, session_id, handler_pid,
handler_count}, where handler_count is the number of SSE handlers
connected after this registration. Measurements: %{count: 1,
system_time: System.system_time()}.
Purely additive: no change to the register flow, keepalive, or reply.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
611268e to
5ccd9d5
Compare
Removed telemetry signal emission comments for SSE handler registration.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
zoedsoupe
changed the title
## Problem
The Streamable HTTP transport has telemetry for transport
init/connect/disconnect/terminate but no signal for the moment a client
(re)attaches an SSE handler to a session. That reconnect point is
exactly where hosts need a hook -- e.g. to observe standalone GET/SSE
stream churn, or to react when a client reconnects after a zero-handler
gap.
## Solution
- Add `Anubis.Telemetry.event_transport_sse_handler_registered/0`
returning `[:transport, :sse_handler, :registered]` (namespaced to
`[:anubis_mcp, ...]` by `Telemetry.execute/3`).
- Emit it from the `{:register_sse_handler, ...}` handler after the
handler is monitored and recorded.
- Metadata: `%{transport: :streamable_http, server: term(), session_id:
String.t(), handler_pid: pid(), handler_count: non_neg_integer()}`,
where `handler_count` is the number of SSE handlers connected after this
registration. Measurements: `%{count: 1, system_time:
System.system_time()}`.
Purely additive: no change to the register flow, keepalive, or reply.
## Rationale
Not spec-mandated; this is a library observability affordance for the
Streamable HTTP transport's SSE-stream lifecycle. It fills the one gap
in the existing transport telemetry family (there are
connect/disconnect/terminate events but nothing for per-handler
re-attach), and it pairs naturally with `Last-Event-ID` resumability by
exposing the reconnect trigger.
## Tests
Adds a transport test that attaches a `:telemetry` handler and asserts
the event fires once on registration with the documented metadata shape
and a `handler_count` reflecting the connected set.
---------
Co-authored-by: zoey <zoey.spessanha@zeetech.io>
🚀 Want to release this? --- ## [1.9.0](v1.8.0...v1.9.0) (2026-07-16) ### Features * **streamable_http:** add spec resumability (Last-Event-ID replay) ([#216](#216)) ([78e33b4](78e33b4)) * support pre_initialized sessions for cross-pod restore ([#187](#187)) ([13be0d7](13be0d7)) ### Bug Fixes * **session:** return encodable JSON-RPC errors when init/2 fails ([#211](#211)) ([f9af7cc](f9af7cc)) * **streamable_http:** emit telemetry on SSE handler registration ([#217](#217)) ([4a4c528](4a4c528)) * **streamable_http:** restore session from store on notif/resp registry miss ([#221](#221)) ([d757b39](d757b39)) * **streamable_http:** return correct JSON-RPC error codes for parse failures ([#222](#222)) ([1867994](1867994)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
2 participants
Problem
The Streamable HTTP transport has telemetry for transport init/connect/disconnect/terminate but no signal for the moment a client (re)attaches an SSE handler to a session. That reconnect point is exactly where hosts need a hook -- e.g. to observe standalone GET/SSE stream churn, or to react when a client reconnects after a zero-handler gap.
Solution
Anubis.Telemetry.event_transport_sse_handler_registered/0returning[:transport, :sse_handler, :registered](namespaced to[:anubis_mcp, ...]byTelemetry.execute/3).{:register_sse_handler, ...}handler after the handler is monitored and recorded.%{transport: :streamable_http, server: term(), session_id: String.t(), handler_pid: pid(), handler_count: non_neg_integer()}, wherehandler_countis the number of SSE handlers connected after this registration. Measurements:%{count: 1, system_time: System.system_time()}.Purely additive: no change to the register flow, keepalive, or reply.
Rationale
Not spec-mandated; this is a library observability affordance for the Streamable HTTP transport's SSE-stream lifecycle. It fills the one gap in the existing transport telemetry family (there are connect/disconnect/terminate events but nothing for per-handler re-attach), and it pairs naturally with
Last-Event-IDresumability by exposing the reconnect trigger.Tests
Adds a transport test that attaches a
:telemetryhandler and asserts the event fires once on registration with the documented metadata shape and ahandler_countreflecting the connected set.