Is your feature related to a problem? Please describe.
Endpoints in an NServiceBus system subscribe to events, and those subscriptions accumulate over their lifetime. An endpoint is decommissioned, a message type is retired, or a subscription is created that never should have existed — yet the subscription record lingers. Depending on the transport, that record lives either natively in the broker (topics/rules/bindings) or in a subscription store held in persistence. Stale subscriptions keep events being routed to queues no one reads and make it hard to answer a basic operational question: who is subscribed to this message type?
There is currently no way to inspect or clean up subscriptions from ServicePulse or ServiceControl. To see who subscribes to a given message type, or to remove a subscription that is no longer needed, an operator has to go directly to the underlying infrastructure — a database administrator querying the subscription table, or a broker/cloud administrator inspecting the transport's topology. That requires infrastructure-level access and transport-specific knowledge that the teams who actually own the endpoints often do not, and should not, have.
The result is a bottleneck. Routine, application-level lifecycle work — removing a subscription for a message type that is no longer sent or handled — has to be escalated to infrastructure or platform teams. This slows the owning teams down, and it forces broad transport/database access to be granted for a narrow task, which is itself a least-privilege problem.
This affects teams operating publish/subscribe systems on the platform: publishing teams who need to see and clean up subscribers to their events, receiving teams cleaning up their own stale subscriptions, and platform/infrastructure teams who become an unwanted gatekeeper for routine work.
This need was raised on the community forum: https://discuss.particular.net/t/we-need-your-input-authorization-is-coming-to-servicepulse-and-servicecontrol/4648.
Describe the requested feature
Operators should be able to view existing subscriptions — which endpoints are subscribed to which message types — and remove subscriptions that are no longer needed, from within the platform, without requiring direct access to the underlying transport or subscription database.
This issue is intentionally about the problem and the capability, not the mechanism. How subscriptions are surfaced and managed (UI, API, per-transport support, etc.) is a design decision to be worked out separately.
Out of scope for this issue: who is allowed to manage which subscriptions — authorization and per-team endpoint scoping. That depends on the role-based access control work (see #5585) and the planned resource-scoping capability, and is deliberately not addressed here.
Describe alternatives you've considered
- Manage subscriptions directly in the transport/database (current state). Requires infrastructure-level access and transport-specific knowledge, forces routine work to be escalated to infrastructure teams, and over-grants privilege for a narrow task.
- Per-transport scripts against the subscription store. Brittle, transport-specific, easy to get wrong, and not self-serve for the teams that own the endpoints.
Is your feature related to a problem? Please describe.
Endpoints in an NServiceBus system subscribe to events, and those subscriptions accumulate over their lifetime. An endpoint is decommissioned, a message type is retired, or a subscription is created that never should have existed — yet the subscription record lingers. Depending on the transport, that record lives either natively in the broker (topics/rules/bindings) or in a subscription store held in persistence. Stale subscriptions keep events being routed to queues no one reads and make it hard to answer a basic operational question: who is subscribed to this message type?
There is currently no way to inspect or clean up subscriptions from ServicePulse or ServiceControl. To see who subscribes to a given message type, or to remove a subscription that is no longer needed, an operator has to go directly to the underlying infrastructure — a database administrator querying the subscription table, or a broker/cloud administrator inspecting the transport's topology. That requires infrastructure-level access and transport-specific knowledge that the teams who actually own the endpoints often do not, and should not, have.
The result is a bottleneck. Routine, application-level lifecycle work — removing a subscription for a message type that is no longer sent or handled — has to be escalated to infrastructure or platform teams. This slows the owning teams down, and it forces broad transport/database access to be granted for a narrow task, which is itself a least-privilege problem.
This affects teams operating publish/subscribe systems on the platform: publishing teams who need to see and clean up subscribers to their events, receiving teams cleaning up their own stale subscriptions, and platform/infrastructure teams who become an unwanted gatekeeper for routine work.
This need was raised on the community forum: https://discuss.particular.net/t/we-need-your-input-authorization-is-coming-to-servicepulse-and-servicecontrol/4648.
Describe the requested feature
Operators should be able to view existing subscriptions — which endpoints are subscribed to which message types — and remove subscriptions that are no longer needed, from within the platform, without requiring direct access to the underlying transport or subscription database.
This issue is intentionally about the problem and the capability, not the mechanism. How subscriptions are surfaced and managed (UI, API, per-transport support, etc.) is a design decision to be worked out separately.
Out of scope for this issue: who is allowed to manage which subscriptions — authorization and per-team endpoint scoping. That depends on the role-based access control work (see #5585) and the planned resource-scoping capability, and is deliberately not addressed here.
Describe alternatives you've considered