<div dir="auto"><div dir="auto">Yes, other changes can potentially affect a stream beyond its status—such as configuration modifications, metadata updates, or permissions adjustments. However, in the current system design, only StreamUpdate events that carry status information are emitted because these events are specifically targeted to reflect the state transitions of the stream itself (e.g., creation, deletion, active, inactive). </div><div dir="auto"><br></div><div dir="auto">Focusing on status allows for streamlined event processing and simplifies downstream handling, ensuring that components respond correctly to the lifecycle changes of streams. If other types of updates (like metadata changes) need to be propagated, additional event types can be introduced, but for monitoring the stream’s lifecycle, status-focused StreamUpdate events are sufficient and efficient. </div><div dir="auto"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Aug 19, 2025, 1:01 PM github--- via Openid-specs-risc <<a href="mailto:openid-specs-risc@lists.openid.net">openid-specs-risc@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
openid/sharedsignals event <br>
<br>
Issue opened <br>
Issue Title: Tx sending a Stream Update Event for stream deletion <br>
<a href="https://github.com/openid/sharedsignals/issues/287" target="_blank" rel="noreferrer">https://github.com/openid/sharedsignals/issues/287</a> <br>
<br>
Here is the discussion we had in the WG meeting about this topic: - (Yair) The spec says to send a Stream Update event when the status changes. - (Yair) Do we need a "deleted" status to send when a stream is deleted? - (Thomas) If we don't add a deleted status,
how will Receivers know that resources should be cleaned up? - (Mike) Does that imply that streams live on forever with status "deleted"? - (Yair) No, the stream would be deleted and gone. - (Thomas) What happens for Receivers that don't get the event? - (Yair)
This event is for the benefit of the Receiver. - (Thomas) But that means the stream can only be deleted after the deleted event was consumed. - (Yair) I don't think the stream should wait for the event to be delivered before deleting - (Thomas) Should we use
something like the inactivity timeout to say the stream should hang around for a specific amount of time after the event is sent before deleting itself? - (Shayne) It's a little bit strange to think about status of "deleted". I wonder if we want a new event,
StreamDeleted. - (George) I agree with the idea of a specific event. There is no way to guarantee that the Receiver will receive the event, but having a mechanism to alert in an optimistic case is nice. - (George) Both the Transmitter and Receiver should have
some documented logic to determine when a stream is no longer active. This new event is an optimization, but the fallback mechanisms have to be present as well. - (Yair) What is the expectation today for what happens when a stream is deleted? - (Shayne) I
don't think we have any expectations today. - (Yair) For now, we could send a "disabled" status before deleting the stream - (Shayne) I'm not against the idea of sending a "disabled" in this case. What does the Receiver do when it gets that event? - (Yair)
I would expect that getting an unexpected disabled status would alert a human operator. - (Mike) Someone might trigger a verficiation event which would then return a 404 because the stream would no longer exist. Is the expectation that a 404 should cause the
Receiver to shut down the stream on their end? - (Yair) I would expect that the customer or Receiver host would want to trigger some kind of investigation - (Shayne) Does the deleted event vs a 404 change the customer's behavior? - (Yair) It depends on whether
the customer triggered the action - (Shayne) A deleted event might be a nice thing for a Receiver that requests the deletion. - (Mike) A 204 from the delete request should be the thing that tells the Receiver the deletion was successful. - (Thomas) What about
multiple Receivers on the same stream? - (Mike) It feels cleaner to have a deleted event to go out before deletion - (Thomas) Possible race condition without some kind of timeout before deleting the stream - (Yair) For push streams, that shouldn't be a problem,
but poll streams do have that issue - (Shayne) One more argument for making this an event not a status is that statuses seem to talk about whether events can "enter" the stream, not whether they can be broadcasted over the stream. - (Yair) Is there any other
change that can affect the stream besides status? If so, why do we only have StreamUpdate events with status info? - (Shayne) Some examples of things that could change - the Tx could add or remove subjects, could change the delivery method, could change timeout
intervals. We don't really restrict the Tx's actions. - (Shayne) What I'm hearing is that maybe we want to extend StreamUpdated to cover more than just status changes. Then we are not creating a new event type for stream deletion, but just adding new metadata
to the StreamUpdated event.
</div>
_______________________________________________<br>
Openid-specs-risc mailing list<br>
<a href="mailto:Openid-specs-risc@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-risc@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-risc" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-risc</a><br>
</blockquote></div>