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
平均合并
9 小时 54 分钟
30 天内合并 PR
11

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

softwaremill/okapi 的其他 Issue

查看 softwaremill/okapi 的全部 Issue

相似的 Issue

更多 Kotlin Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。