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

[ysarig75]

No description provided.

Pressed approve by accident

[FragLegs]

This just occurred to me - the Transmitter might choose to drop events regardless of the stream status. Should we move this language elsewhere?

[tulshi]

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.

[ysarig75]

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.

AFAIK, we don't have a mention of polling logic anywhere in the spec (i.e., we mention polling and pushing with information about how to configure them but we don't specify anything about the polling behavior). So if we want to add language about the polling behavior, where should we add it in the spec?

[FragLegs]

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

[tulshi]

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

[tulshi]

@ysarig75 please also bump up the version number and date.

[ysarig75]

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.

[ysarig75]

@FragLegs / @atultulshi What is the next step for this PR?
I can see the following options:

1. Only address the pause issue and merge the PR as is (as we need to address the larger issue anyway in the future)
2. Add some additional language to address the polling issue
3. Something else?

[tulshi]

I've approved. We need one more.