OutboxProcessorListener events are emitted before the transaction commits; metrics over-count on commit failure

未關閉
#137 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

@rawo 已經在處理了。

開始於 2026年11月6日。

  • #147 來自 @rawo —— 未關閉

評估

難度
4/5
預估耗時
3-5 天
新手友好度
35/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
kafka, kotlin, mysql, postgresql, spring-boot
領域
backend

研究方向

Start in OutboxProcessor.processNext, where listener.onEntryProcessed runs right after store.updateAfterProcessingBatch and before the transaction commits. Then read OutboxScheduler and the TransactionRunner used around runInTransaction to see where an after-commit notification could go. Done means listener callbacks fire only after a successful commit, or the pre-commit behaviour is documented; the design choice needs maintainer input first.

由索引模型根據 Issue 內容生成。

描述

breaking-change bug

Severity: Low · Area: okapi-core OutboxProcessor listener notifications · Found in: code review of main @ e5630a1

Problem

OutboxProcessor.processNext calls listener.onEntryProcessed(...) (Delivered / RetryScheduled / Failed) right after store.updateAfterProcessingBatch, while still inside the scheduler's transaction, before it commits. If the commit then fails (connection loss, serialization failure, server-side timeout), the DB rolls back to PENDING, but okapi.entries.delivered and okapi.entries.failed have already been incremented. The rows are delivered again next tick and counted again.

Metrics therefore over-report successful deliveries in exactly the failure scenarios where operators rely on them. A custom listener that does something non-idempotent (e.g. notifying another system) would act on a state that was never persisted.

Suggested fix

Defer listener callbacks until after the transaction commits: for example, return the processed entries from the transactional block and notify in OutboxScheduler after runInTransaction returns, or register an after-commit hook through TransactionRunner. At minimum, document that events are pre-commit.

主要語言
Kotlin
星號
14
分支
0
平均合併
14 小時 16 分鐘
30 天內合併 PR
9

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南,環境需要你自己搭建:先看它的 README,通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

softwaremill/okapi 的其他 Issue

查看 softwaremill/okapi 的全部 Issue

相似的 Issue

更多 Kotlin Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。