oscerd commented on PR #3057: URL: https://github.com/apache/camel-kamelets/pull/3057#issuecomment-5791092237
Update, and a correction to my own last comment. CI is now **green on this branch** (`test` 31m42s), and #3033 has also gone green on a re-run **without** this change (`test` 27m0s). Same code, red then green, on both sides. So the failure is intermittent in CI, not deterministic. That undoes the flat claim I made above that this change "does not fix the failure" — I based that on a single red run, which was no more conclusive than the single green run I would have pointed at as proof if the order had been reversed. One part of my reasoning there was also weaker than I made it sound. I argued a second timer firing was impossible because the failing tests took 7.3s and 10.8s, under or near the ten second period. But those are Citrus test durations, measured from the test starting, not from the route starting — the integration is launched before, so more than ten seconds can easily have passed since the first firing. That argument does not rule the race out. Where this honestly stands: the failure is intermittent on both sides, `repeatCount: 1` is a plausible narrowing of the window, and **one green run does not demonstrate it any more than one red run disproved it.** The change stands on its own terms regardless — the tests assert exactly one specification fetch followed by one operation call, so the route sending exactly one message matches what is being asserted. Leaving it in draft. It is a reasonable hardening rather than a demonstrated fix, and I would rather it be merged, or not, on that basis than on a claim I cannot support. --- _Claude Code on behalf of Andrea Cosentino_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
