streamable-http-client: RequestHandle::cancel hangs before response stream starts #1193

Activity

1. DaleSeo

   added

   P1High: significant functionality gap or spec violationHigh: significant functionality gap or spec violation

   needs confirmationBug report that needs verification from a maintainerBug report that needs verification from a maintainer

   T-transportTransport layer changesTransport layer changes

   on Aug 28, 2026
2. LizunovSergey commented on Sep 12, 2026

   

   LizunovSergey

   on Sep 12, 2026

   More actions

   This looks fixed on current main (b86995a) — by #1186, which merged on 2026-08-24, five days after this was filed. That would explain why it is still open with the needs confirmation label.

   The ordering the issue describes has been inverted. Worker::post_request now takes the request's cancellation token before issuing the POST and races the two:

   let cancellation = send_request
       .cancellation_token()
       .unwrap_or_else(|| transport_cancellation.child_token());
   Box::pin(async move {
       let response = tokio::select! {
           biased;
           _ = cancellation.cancelled() => None,
           _ = send_request.responder.closed() => None,
           ...
           response = client.post_message_with_max_sse_event_size(...) => Some(response),
       };

   So the token is no longer "registered only after the POST produces an SSE response" — a POST still waiting for its first response event is cancellable.

   Check I ran. Using the repo's own scripted-transport harness in tests/test_streamable_http_client_concurrency.rs, which lets the test hold a request POST pending, with ClientLifecycleMode::Discover { preferred_versions: vec![ProtocolVersion::V_2026_07_28] } to match the conditions here:

   let mut harness = Harness::with_lifecycle(
       config(),
       ClientLifecycleMode::Discover { preferred_versions: vec![ProtocolVersion::V_2026_07_28] },
   ).await?;
   let hanging = harness.cancellable("hanging").await?;
   let blocked = harness.next().await; // POST in flight, reply deliberately withheld
   
   timeout(Duration::from_secs(5), hanging.cancel(None))
       .await
       .expect("RequestHandle::cancel should not wait for the response stream")?;

   That passes — cancel returns immediately instead of timing out after five seconds.

   Two caveats, so this is confirmation rather than proof: it drives a scripted StreamableHttpClient rather than a live Axum listener, so it pins the client-worker ordering (which is where the issue located the bug) and not the server's reaction to the closed stream; and I did not test against the @webclaw/mcp-style setup in the original repro.

   Worth noting that no existing test names this scenario — the closest are cancellation_still_runs_while_recovery_waits_for_old_posts and cancellation_bypasses_queued_posts_at_capacity, both of which pin cancellation against other traffic rather than against the request's own pending POST. If you would like the case above locked in as a regression test so it cannot silently return, I am happy to send that as a small PR — say the word and I will open one.
3. lucarlig

   closed this as completedon Sep 16, 2026