neuron-tai/.scratch/proxy-stream-cancellation/issues/01-direct-sse-cancellation-race.md

PSC-001 — Direct SSE cancellation race

Status: ready-for-agent Priority: High

Problem

tests/test_tracker_routing.py::test_tracker_dashboard_can_cancel_inflight_proxy registers a streaming upstream node. The upstream writes and flushes the first SSE frame, then waits three seconds. The tracker’s client does not receive that frame until after the upstream has completed; by then _unregister_active_proxy() has run and the dashboard cancellation endpoint returns 404.

Observed trace:

proxy route selected
proxy connected
proxy progress ... elapsed_seconds≈3
proxy complete ... elapsed_seconds≈3
POST /v1/proxy/requests/<id>/cancel → 404

This is a production cancellation/delivery race, not a stale test: the endpoint promises to cancel active proxy work, and the upstream had already emitted a first stream frame before cancellation was attempted.

Acceptance criteria

• A direct SSE upstream frame is relayed and flushed to the client before the upstream completes.
• After that first frame, /v1/proxy/requests/{request_id}/cancel returns 200 while the stream is active.
• Cancellation closes/stops the upstream safely, finalizes inflight accounting exactly once, and records the cancellation event.
• Cancel authorization remains unchanged.
• Client disconnect and normal SSE completion retain current billing/throughput behavior.
• Regression test is deterministic and does not rely on timing races longer than necessary.
• Focused tracker routing tests and full pytest are run with unrelated failures documented.

Likely seam

Inspect direct streaming behavior around _handle_proxy_chat upstream reads (packages/tracker/meshnet_tracker/server.py, roughly lines 3953–4019). The direct response path writes/flushed each line, but current HTTP response buffering/reading prevents the line from being observed until stream end. Fix delivery at the proxy transport boundary; do not paper over it by retaining completed proxy records indefinitely.