[Bug] AppendTableITCase.testCompactionInStreamingMode is flaky and can time out under CI load
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 78/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- java
调研方向
从 AppendTableITCase.testCompactionInStreamingMode 及其同级测试 testCompactionInStreamingModeWithMaxWatermark 开始。在类似 CI 的负载下运行测试，并检查其 60 秒轮询限制；完成意味着两个测试都能可靠地观察到 COMPACT 快照而不会超时。
由索引模型根据 Issue 内容生成。
描述
Search before asking
- I searched in the issues and found nothing similar.
Paimon version
master (645ce6f8d)
Compute Engine
Flink
Minimal reproduce step
AppendTableITCase.testCompactionInStreamingMode, and its sibling testCompactionInStreamingModeWithMaxWatermark, run a streaming INSERT from a datagen source at rows-per-second = 1 into an append table configured with compaction.min.file-num = 4, continuous.discovery-interval = 1 s, and a 500 ms checkpoint interval. They then poll once a second, for up to 60 s, for a snapshot whose commitKind is COMPACT.
In CI the poll sometimes reaches the 60 s limit and the test fails:
java.lang.RuntimeException: Time up for streaming execute, don't get expected result.
One example: https://github.com/apache/paimon/actions/runs/36149147465/job/108117843839
What doesn't meet your expectations?
The test should not time out. Nothing is broken in the append-compaction pipeline; the failure is a timing race inside the test.
On a healthy run the first COMPACT snapshot arrives in under 20 s: the streaming job starts, four small files accumulate at about one per second, the coordinator picks them up on its next discovery cycle, compaction runs, and the compacted snapshot commits. The 60 s budget is usually comfortable. Under CI load, streaming job deployment and checkpoint/commit progress can stall, and the first COMPACT snapshot occasionally shows up after 60 s.
The same test was reported in #1634 and closed without a fix.
Anything else?
#1634 suggested lowering compaction.min.file-num as a workaround. That only shortens the file-accumulation phase (roughly 4 s at one file per second), which is not where the time goes when the test times out. The stall is in job deployment and checkpoint progress, so giving the wait a larger timeout is the direct fix.
Are you willing to submit a PR?
- I'm willing to submit a PR!
- 主要语言
- Java
- 星标
- 3.4k
- 派生
- 1.4k
- 平均合并
- 1 天 10 小时
- 30 天内合并 PR
- 472
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
apache/paimon 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 88/100
apache/arrow-java#1311 ·
维护者通常 2 天内回复
-
bug triage
难度 2/5 1-3 小时 新手友好度 85/100
-
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
security
难度 2/5 1-3 小时 新手友好度 65/100
IBM/networking-java-sdk#204 ·