<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue Comment created on issue 256 <br>

Issue Title: Clarifying the language around the retention of events while a stream is paused

<br>

https://github.com/openid/sharedsignals/pull/256 <br>

<br>

Comment: > > > > This just occurred to me - the Transmitter might choose to drop events regardless of the stream status. Should we move this language elsewhere? > > > > > > > > > I'd rather be very specific about when this can happen. AFAIK this can happen

 when the Receiver doesn't poll frequently enough or the stream is paused. Any other condition? If so, we can just add the same / similar language to the poll delivery section. > > > > > > I can think of a number of other cases: > > > > * Transmitter pushes

 the event and gets an error code from the Receiver > > * Receiver polls frequently but never acks one or more of the SETs > > * The event source overwhelms the Transmitter's ability to deliver events (poll or push) > > * The Receiver changes the event types

 requested or the subjects on the stream while an event has not yet been delivered > > true, so perhaps we can move the language to the Event Delivery section? We should make a new section before the "Push delivery" section, which can talk about conditions

 under which the Transmitter may drop events Not all the reasons why an event may not be delivered are the same. * Transmitter pushes the event and gets an error code from the Receiver: In this case, the transmitter tried to deliver and it failed. There are

 many possible ways how the failure can be handled (dropping the event, retrying N times and then dropping the event, retrying with a back off, pausing the stream and reaching out to the receiver in unspecified way to triage the issue). * The event source overwhelms

 the Transmitter's ability to deliver events (poll or push): The transmitter may not have the missing events in this case and it is more of an implementation/operation issue * The Receiver changes the event types requested or the subjects on the stream while

 an event has not yet been delivered: Is this really an issue? The receiver explicitly asked to change which events are being sent to it so it doesn't want the extra events. It will be the same if the receiver disable a stream while there were events in processing

 by the transmitter So maybe we should only address pause and poll issues in this PR.

</body>

</html>