oscerd commented on PR #3057:
URL: https://github.com/apache/camel-kamelets/pull/3057#issuecomment-5776323783
Marking this draft: **it does not fix the failure.** CI is still red on
exactly the same two tests with this change applied.
My reasoning was wrong, twice over.
**The timer race does not explain it.** With `repeatCount: 1` there is one
firing and one exchange, yet the run still sees a second
`/petstore/openapi.json` where the operation is expected — and the failing runs
here took 7.3s and 10.8s, under the ten second period, so a second firing could
not have occurred even without the change.
**The Camel version does not explain it either.** I thought CI ran a newer
Camel than my machine and tried to pin the version with
`citrus.camel.jbang.version`. The prefix in this module is
`citrus.camel.cli.*`, so that property was ignored and the two runs I read as
confirmation proved nothing. The existing configuration already sets
`citrus.camel.cli.version=${camel.version}`, so CI and local should be on the
same Camel.
Where that leaves it: the component issues a second specification fetch for
a single exchange, consistently in CI and not on my machine, and I cannot
currently reproduce it locally to find out why.
The `repeatCount: 1` line is still defensible on its own — the tests assert
exactly one cycle, so the route should send exactly one message — but that is
tidying, not a fix, and it should not be merged under a title claiming
otherwise. Happy to close this, or to reopen it as a small hardening change
once the real cause is understood.
---
_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]
