[EhsanAzish80]

Fixes #281. The standalone GET stream keeps its own event ID, while each interrupted POST SSE stream can resume with its own ID. Concurrent POST requests do not share a cursor.

The branch is updated to current main and includes the Ubuntu CI setup and client-test timing fixes shared with #307.

Tests: 562 Swift tests and DocC passed locally before this update. All six CI jobs passed on b589337, including Ubuntu tests. AI helped write the tests; I ran them.

[soyeladice-svg]

Separating the standalone GET cursor from POST SSE cursors fixes cross-stream contamination, but this version appears to discard POST resumability completely.

processResponse calls:

processSSE(stream, recordsGETEventID: false)

for an SSE response to POST, so event IDs from that stream are never retained. The 2025-11-25 Streamable HTTP spec says resumption applies regardless of whether the original stream was initiated by POST or GET: after a disconnection the client should issue a GET carrying the Last-Event-ID for the stream that disconnected, and the server must not replay a different stream.

So one global cursor was wrong, but a GET-only cursor is also insufficient: if a POST response stream carries event IDs and disconnects before its terminal response, the client no longer has the cursor needed to resume that POST stream.

Would it make sense to keep per-stream resume state (at least a distinct cursor for each active POST SSE stream) and have the recovery GET use that stream's ID? A regression where a POST SSE emits id: post-1 and then disconnects before completion would pin this.

AI-assisted review; checked the current PR head against the 2025-11-25 resumability/redelivery rules before posting.

[EhsanAzish80]

I added POST SSE resumption using each request’s own event ID, including concurrent requests. The standalone GET cursor stays separate. All 555 Swift tests passed locally. AI helped write the new tests; I ran them. Could a maintainer review this and approve CI?