Add routes for platform-driven automatic DLQ retries#162
Conversation
|
| fun automatedRetry(processingGroup: String, messageIdentifier: String): Boolean { | ||
| val entry = dlqFor(processingGroup) | ||
| val success = entry.processor.process { it.message().identifier() == messageIdentifier } | ||
| .get(60, TimeUnit.SECONDS) |
There was a problem hiding this comment.
A client-side timeout here escapes the retry budget. process { … }.get(60, SECONDS) throws TimeoutException when a sequence takes longer than 60s to process, rather than returning false — so the if (!success) branch never runs, registerFailedAutomatedAttempt is skipped, and __platform_retries is never incremented.
The effect: a sequence that consistently fails by being slow (>60s) is retried every scheduled round forever and never counts toward maxRetries. The platform side (DlqRetryExecutor.retry, timeoutSeconds = 90) just catches the resulting error and moves on, so nothing upstream compensates.
Suggest catching the TimeoutException around the .get(...) and treating it as success = false, so a timed-out attempt flows through the existing failure path (bumps the counter) and returns false like any other failed attempt. Worth a test for the "slow sequence eventually exhausts its budget" case.
2 participants
Supports automatic DLQ retries in the platform (AxonIQ/axoniq-platform#731). The client owns due-sequence filtering and attempt counting, since the framework doesn't track retries by default.