search

openid / sharedsignals

OpenID Shared Signals Working Group Repository
45 stars 11 forks source link

Expected Response When Polling After Stream Delete #128

Closed independentid closed 1 month ago

independentid commented 9 months ago

If a transmitter polling stream is "deleted" before the receiving entity "shuts down", it is unclear what should happen at the polling endpoint. How graceful should the shut down be?

Note: I see notation that Paused or Disabled event should send a Stream-updated-event upong being re-enable, but no mention is made of sending event when changing state to pause or disabled.

If a stream is disabled or deleted it would be useful for a period of time for the polling endpoint to indicate in the polling response that the Stream is disabled or deleted (e.g. include status response attributes). This allows the poller to download remaining events, detect the change and exit gracefully.

Eventually after all events are gone, specify status 404 is to be returned. Or specify status 410 Gone to indicate the stream has been removed (though the url was valid).

FragLegs commented 1 month ago

It may have been added since this issue was created, but the spec does say that the Transmitter MUST emit a Stream Updated event when going from enabled to paused/disabled as well as when going from paused/disabled to enabled. We don't currently model the idea of a deleted stream, but we could add a recommendation that if the Transmitter is going to delete a stream, they disable it first with a reason explaining that deletion is imminent.

FragLegs commented 1 month ago

Actually, there appears to be conflicting language in the spec. In section 7.1.2 it says the Transmitter SHOULD/MAY send a Stream Updated event when going from paused/disabled to enabled (respectively). But in section 7.1.5, it says MUST. We should update 7.1.2 to also say MUST.