Tx sending a Stream Update Event for stream deletion

[ysarig75]

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.