You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit d292cba
Browse filesBrowse the repository at this point in the historyBrowse files
fix(core): address review of after-commit listener events (#137)
- TransactionRunner documents its contract: runInTransaction has committed when it returns, and may
run the block more than once (Exposed retries).
- publishEvents reads the batch end time before the callbacks and is one-shot per batch;
ProcessedBatch exposes a read-only entry list and a toString.
- Fix stale processNext references.
- Tests: the end-to-end test runs with SpringTransactionRunner and ExposedTransactionRunner as well
as plain JDBC and fails fast if the row is missing; unit tests for a retrying runner, a failing
processBatch and double publishing.
- Docs: counters count committed status changes; batch timer wording; how a listener that relied on
the processing transaction now fails.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
| `okapi.batch.duration` | Timer | Processing time per batch, from the claim until the transaction has committed |
276
+
| `okapi.batch.duration` | Timer | Processing time per batch; under the scheduler from the claim until the transaction has committed (not including listener callbacks) |
| `okapi.entries.lag.seconds` | Gauge | Age of the oldest entry (tag: `status`) |
279
279
@@ -291,7 +291,7 @@ max by (job, status) (okapi_entries_count)
291
291
292
292
Without Spring Boot, construct `MicrometerOutboxListener` and `MicrometerOutboxMetrics` with your `MeterRegistry`. Refresh gauges with `OutboxMetricsRefresher` or your own scheduler.
293
293
294
-
For custom reactions to delivery events, implement `OutboxProcessorListener`. `OutboxProcessor` takes a single listener; combine several with a composite of your own. The scheduler calls the listener after the processing transaction has committed, outside of it, and not for a batch whose commit failed, so every event describes persisted state and counters do not over-count when a commit fails. If you drive `OutboxProcessor` yourself, call `processBatch` inside your transaction and `publishEvents` after it commits; `processNext` does both at once, so inside a transaction its events precede the commit.
294
+
For custom reactions to delivery events, implement `OutboxProcessorListener`. `OutboxProcessor` takes a single listener; combine several with a composite of your own. The scheduler calls the listener after the processing transaction has committed, outside of it, and not for a batch whose commit failed, so every event describes persisted state and counters do not over-count when a commit fails. Counters therefore count committed status changes, not delivery attempts: a send whose transaction then rolled back (a failed commit, or a block Exposed retried) is not counted, though the message may have reached the consumer. If you drive `OutboxProcessor` yourself, call `processBatch` inside your transaction and `publishEvents` after it commits; `processNext` does both at once, so inside a transaction its events precede the commit.
Copy file name to clipboardExpand all lines: okapi-integration-tests/src/test/kotlin/com/softwaremill/okapi/test/transaction/ListenerAfterCommitEndToEndTest.kt
0 commit comments