24 lines
1.5 KiB
Plaintext
24 lines
1.5 KiB
Plaintext
$ mvn -pl outbox -am test -Dtest=ReplayIncompletePublicationsTest
|
|
(FlakyAuditListener throws on its first invocation of InvoiceIssued, succeeds on every
|
|
one after -- standing in for any downstream dependency that is briefly unavailable)
|
|
|
|
Incomplete FlakyAuditListener publications after the simulated failure: 1
|
|
Incomplete FlakyAuditListener publications after resubmission: 0
|
|
Invoice 1 never changed -- the retry was purely about redelivering the event, the invoice row was correct the whole time.
|
|
|
|
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
|
|
|
|
The sequence that actually ran: BillingManagement.issueInvoice() commits the Invoice
|
|
row and the EVENT_PUBLICATION row for FlakyAuditListener in one local transaction.
|
|
FlakyAuditListener.on(InvoiceIssued) is then invoked asynchronously, throws on purpose,
|
|
and the registry leaves that row with COMPLETION_DATE still null -- "incomplete" is
|
|
exactly that: a row with no completion date, regardless of whether the listener ever
|
|
ran at all or ran and failed. Calling
|
|
IncompleteEventPublications.resubmitIncompletePublicationsOlderThan(Duration.ZERO) --
|
|
a real method on a real interface, verified against the compiled events-api 2.1.1 jar,
|
|
not assumed from documentation prose -- re-invokes the listener for every such row.
|
|
This time failNextAttempt is already false, so it succeeds, and the row's completion
|
|
date is set. The invoice itself was never touched by any of this: the retry is about
|
|
redelivering a notification, not about redoing a database write that already
|
|
succeeded the first time.
|