FragLegs
commented
12 months ago I agree that we should add reason to the response from the [GET] /status call.
For errors that may occur, I think it is on each individual Transmitter to handle as they see fit. We do have a StreamUpdated event that allows the Transmitter to update the status of a stream without a request from the Receiver. This event includes a reason that could be stored in the same place as the reason data from a Receiver-driven status change, and reported in the same way from a [GET] /status call.
We may have to think about how #56 impacts the reason in a [GET] /status response. That is, if the stream status is disabled but the stream's subject status is enabled, then we need to return "disabled" with the stream's reason value.
When updating a stream status, the requestor is able to provide a reason for the state change.
However if a receiver wants to find out why they are not getting events the status response does not include "reason", also the valid status values do not indicate an error (just enabled, paused, or disabled).
As an example if a push stream errors out because of too many delivery failures, invalid endpoint, authorization failure, the receiver might not know why the stream was paused (or errored out). Is there a problem? Or are there no events that have occurred?
Doing a periodic verify (as a health check) may help. But I wonder if connectivity reliability issues would show up here. For example, a high-rate of posts may get throttled or suffer some other issue requiring administrative intervention by the receiver.
This was a concern I recall being expressed by several orgs during the development of RFC8935.