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.

[tulshi]

We could define a status named "pending deletion" or something like that to indicate that the stream is about to be deleted by the Transmitter. That way, the receiver can expect the stream to be deleted soon, and clean up on its side.