Get a subscription's delivery health
Rolls one subscription’s delivery record into a single non-secret view: outcome counts over the hub’s window and over the last 24 hours, dead-lettered and poison-event counts, the auto-disable verdict, the success rate and the consumer lag.
It answers the question none of the other subscription reads can: whether the events this tenant subscribed to are ACTUALLY ARRIVING. Listing a subscription proves it is registered and enabled; only this shows whether the endpoint behind it has been accepting deliveries.
‘auto_disabled’ and ‘success_rate’ are NULLABLE and null is not the zero value of either. A null ‘auto_disabled’ means the hub holds no endpoint-health row yet, which is not the same fact as false (“checked, and healthy”). A null ‘success_rate’ means no delivery attempt has reached a terminal outcome yet, which is not the same fact as 0.0 (“every attempt failed”). A client that reads either null as its zero value reports a healthy endpoint as broken, or a broken one as fine.
‘disabled_reason’, ‘last_success_at’ and ‘last_failure_at’ are null when there is nothing to report, and the key is always present.
‘status’ and ‘verification_state’ are FREE strings carried through from the hub, not a closed vocabulary this gateway pins. The hub may add a value, and a client should render an unrecognized one by its identifier rather than refuse the response.
This is a FORWARD, not a local read: the gateway owns no subscription storage. The hub answers an unknown subscription and another tenant’s subscription with the SAME 404, publishing no existence oracle, and that 404 reaches the caller unchanged. This gateway does not reinterpret it, because splitting it into “no such subscription” and “not yours” would state something the hub deliberately refused to state.
The tenant is derived from the validated identity and is never read from the request.
Encabezados
Respuesta
OK

