[Openid-specs-risc] openid/sharedsignals: Comment created on issue 256

[github at oidf.org]

openid/sharedsignals event

Issue Comment created on issue 256
Issue Title: Clarifying the language around the retention of events while a stream is paused
https://github.com/openid/sharedsignals/pull/256

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250513/9d702256/attachment-0001.htm>