2.0 KiB
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}/cancelreturns 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.