oscerd commented on PR #3033: URL: https://github.com/apache/camel-kamelets/pull/3033#issuecomment-5773757201
Correction to my previous comment, and a fix. I said the repeated specification fetch looked like a `camel-rest-openapi` behaviour change upstream. **That was wrong.** It is a race inside the test itself, and #3057 fixes it. `rest-openapi-sink-route.yaml` drives both tests from a `timer-source` firing every ten seconds, and it keeps firing. Each test asserts one full cycle: fetch the specification, respond with it, then the operation call. When that cycle runs longer than the period, the next firing's specification fetch lands where the test is waiting for the operation, and the URI comparison fails. What misled me was running it once on `main`, seeing the identical failure, and concluding it was deterministic. Repeating it showed otherwise: one failure then four passes on an unchanged tree, with durations straddling the ten second period. Had I repeated the run before writing, I would not have sent you upstream. The part of my comment that stands is the part that matters here: **these two failures are not caused by your PR.** They reproduce on `main` without anything from your branch, and `rest-openapi` is untouched by the langchain4j change. #3057 adds `repeatCount: 1` so the route sends exactly one message, which is what the assertions describe. Five consecutive runs pass, including runs of 23 and 25 seconds that would previously have been at risk. Once it lands, a rebase should turn this PR green. --- _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]
