[alexluong]

Let a destination type decide whether a failed delivery is retried and counted toward auto-disable, and let it bring its own retry schedule.

Today every failed attempt is retried on the one global schedule and counts toward auto-disable, whatever the cause. A destination type can know better: a failure may be permanent for that request, or say nothing about the endpoint's health. This PR lets the provider that saw the failure say so: the publish error carries the classification, and deliverymq and the alert evaluator act on it. The MCP destination (#1181) is the first user.

No existing destination type sets any of this, so delivery behavior doesn't change.

Changes

1. Publish errors classify themselves. destregistry.ErrDestinationPublishAttempt gains NonRetryable (no automatic retry is scheduled, and exhausted_retries fires right away) and SkipFailureCount (the failure neither increments nor resets the consecutive-failure count). Zero values keep today's behavior. The attempt is still logged as failed, attempt.failed is still emitted, and a manual retry still works.
2. A destination type can bring its own retry policy. A provider can implement the optional destregistry.RetryPolicyProvider; deliverymq resolves it per delivery and falls back to the global policy. The resolved limit drives scheduling, the attempt_max log field and the exhausted_retries alert, so all three agree.

🤖 Generated with Claude Code

[alexbouchardd]

Webhook 410 and 413 are not retried automatically, in both webhook modes. They still count toward auto-disable.

A webhook 410 disables the destination and emits alert.destination.disabled with reason: "endpoint_gone" (the existing reason is "consecutive_failure"). A burst of 410s disables once and alerts once, and a late attempt doesn't disable a destination the tenant has enabled again since.

I don't know about this; there are 2 main issues I see here. First, the decision to use Standard Webhook is currently positioned as a signature decision, not a behavioural one.

Second, there's no way to guarantee that people use those codes as intended, and it's not common knowledge that this would be the behaviour on a webhook call.

Both of these seem very questionable to me

[alexluong]

@alexbouchardd makes sense, I've updated the PR to just support the mechanisms that will be used by MCP Events without changing the existing webhook destination behavior.