Trigger and payload
The guarded service/cancellation services dispatch service.cancellation_requested after their cancellation-request transaction commits. The payload contains service_id.
{"service_id": 123}
Read the current service and its cancellation fields, owning customer, seller and provider mapping. The payload does not include a provider deletion receipt or a refund instruction.
Appropriate use
Create one addon-owned review task or update a permitted internal cancellation view. Deduplicate by the service plus the relevant current request identity in your own records. If multiple core paths request cancellation, repeated delivery must not duplicate external work. An unknown or already completed request should be handled conservatively.
Operational boundary
A request is distinct from financial cancellation and actual remote termination. Do not delete hosting, cancel a registry registration or initiate a refund from this event alone. The installed policy, support review, payment state, provider capability and confirmed remote identity still control those operations. Product-licence expiry must not become a destructive cancellation action.
Test and recover
Test a genuine staging request, repeated delivery, an already closed service and handler failure. Confirm that the originating transaction must commit before your durable addon record appears. Preserve the original cancellation and provider history; recover the addon task through its own reviewed process rather than clearing the core request.