When a domain drops and OrderDomain is dispatched, the OVH connector creates a cart and calls GET /order/cart/{cartId}/domain to check for orderable offers. If OVH's availability API hasn't yet propagated the registry drop, it returns no offer with orderable=true, causing DomainOrderFailedExeption immediately.
The Symfony Messenger retry policy re-attempts 3 times within ~30 seconds (exponential backoff starting at ~1s), which exhausts all retries before OVH's cache updates:
08:06:10 – OrderDomain dispatched (RDAP 404 detected)
08:06:11 – "Unable to complete purchase" (OVH: no orderable offer)
08:06:14 – retry #1 → same result
08:06:17 – retry #2 → same result
08:06:21 – retry #3 → dead lettered
OVH's API only began showing the domain as orderable minutes later. For OVH (and likely other registrars), this lag can be anywhere from 30 seconds to several minutes.
The fix would be to increase retry delays for OrderDomain specifically, e.g. +1 min, +5 min, +15 min. Or distinguish DomainOrderFailedExeption (no orderable offer) from hard failures and give it a longer retry schedule, since it's a transient state.
When a domain drops and
OrderDomainis dispatched, the OVH connector creates a cart and callsGET /order/cart/{cartId}/domainto check for orderable offers. If OVH's availability API hasn't yet propagated the registry drop, it returns no offer withorderable=true, causingDomainOrderFailedExeptionimmediately.The Symfony Messenger retry policy re-attempts 3 times within ~30 seconds (exponential backoff starting at ~1s), which exhausts all retries before OVH's cache updates:
OVH's API only began showing the domain as orderable minutes later. For OVH (and likely other registrars), this lag can be anywhere from 30 seconds to several minutes.
The fix would be to increase retry delays for
OrderDomainspecifically, e.g. +1 min, +5 min, +15 min. Or distinguishDomainOrderFailedExeption(no orderable offer) from hard failures and give it a longer retry schedule, since it's a transient state.