<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
openid/sharedsignals event <br>
<br>
Issue opened <br>
Issue Title: Tx sending a Stream Update Event for stream deletion <br>
https://github.com/openid/sharedsignals/issues/287 <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.
</body>
</html>