[Epic] Reliable stream resumption & event ordering
- Lingua principale
- Shell
- Stelle
- 25.7k
- Fork
- 2.6k
- Merge medio
- 3g 6h
- PR unite (30g)
- 16
Descrizione
## Reliable stream resumption & event ordering
### Problem
Clients today cannot reliably recover a streaming task across a disconnect. There is no per-task event ordering, no cursor to resume from, no defined replay behavior on `tasks/resubscribe`, and ambiguous behavior when more than one stream is active for the same task. This makes long-running tasks fragile in exactly the deployments (proxied, restart-prone) A2A targets.
### Consolidated issues
- [ ] #1794 — Add a generation/version (sequence) number to `Task`/events for ordering, long-polling, and optimistic concurrency *(anchor; `v1.1-candidate`, has gitvote)*
- [ ] #1410 — No "last message ID", so a stream cannot be robustly resumed
- [ ] #1635 — Data loss during SSE reconnection: should `resubscribe` replay missed events?
- [ ] #999 — Behavior of `tasks/resubscribe` with multiple active streams per task *(adjacent: stream multiplexing)*
- [ ] #1811 — Add `TaskMessageUpdateEvent` to notify observers when messages are added to task history
- [ ] #899 — SSE reconnection / event ordering gaps
### Acceptance criteria
- Events (`TaskStatusUpdateEvent`, `TaskArtifactUpdateEvent`) carry a monotonic, per-task sequence/generation number.
- `SubscribeToTask` / `resubscribe` accepts a last-seen cursor and has **defined** replay-or-gap semantics (replay missed events, or an explicit, detectable gap signal).
- Behavior with multiple concurrent subscriptions to one task is specified.
- Changes are reflected in `a2a.proto` and all three bindings (gRPC, REST, JSON-RPC) with binding equivalence preserved.
- Conformance/TCK cases cover reconnect + missed-event detection.
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
This is an epic consolidating multiple issues. Start by reviewing the linked issues, especially #1794 which is the anchor. Understand the a2a.proto definitions for events and the SubscribeToTask/resubscribe methods. The work involves changes across the protocol spec and all three bindings (gRPC, REST, JSON-RPC). 'Done' means implementing sequence numbers, cursor-based resumption, and defined replay semantics, with conformance tests.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Ambito
- api, backend, distributed-systems
- Tipo di issue
- Funzionalità
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Stato di attività
- Tranquilla
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 20/100