[Doc] State the Listen Stream Delivery Semantics
The Subscriptions page documented the acknowledgement-first contract but not what delivery means:
the stream carries only changes that happen after the acknowledgement, nothing is queued while
no stream is connected, and a dropped stream is gone together with anything it missed.
The Python SDK's subscriptions page states the same contract ("It is not a replay log").
Spelling it out gives client implementers the fetch-after-subscribing guidance and
makes the acknowledgement-window behavior explicit.
This commit is contained in:
parent
8e0ae73cc1
commit
ef3eb7b0b2
1 changed files with 7 additions and 0 deletions
|
|
@ -49,6 +49,13 @@ The first SSE event on the stream is the acknowledgement:
|
|||
}
|
||||
```
|
||||
|
||||
## Delivery Semantics
|
||||
|
||||
A stream delivers only the changes that happen after its acknowledgement; it is not a replay log.
|
||||
Nothing is queued while no stream is connected, and a dropped stream is gone together with anything it missed.
|
||||
Clients fetch the current state after subscribing and treat each notification as a cue to refetch,
|
||||
rather than as a payload.
|
||||
|
||||
## Transport Support
|
||||
|
||||
The stream is served on the Streamable HTTP modern path; stdio answers `-32601`.
|
||||
|
|
|
|||
Loading…
Reference in a new issue