oscerd opened a new pull request, #3057:
URL: https://github.com/apache/camel-kamelets/pull/3057

   `rest-openapi-sink-add-pet-test` and `rest-openapi-sink-delete-pet-test` 
fail intermittently:
   
   ```
   Values not equal for header element 'citrus_http_request_uri',
   expected '/petstore/pet' but was '/petstore/openapi.json'
   ```
   
   This is what is currently red on #3033, where it has nothing to do with the 
change under review.
   
   ## Cause
   
   Both tests drive `rest-openapi-sink-route.yaml`, and its `timer-source` 
fires **every ten seconds and keeps firing**.
   
   Each test asserts one complete cycle:
   
   1. `GET /petstore/openapi.json` — the specification fetch
   2. a response carrying the specification
   3. the operation call, `POST /petstore/pet` or the delete
   
   When that cycle takes longer than the period, the **next firing's 
specification fetch** arrives at the point where the test is waiting for the 
operation, and the URI comparison fails.
   
   ## Why it looks random
   
   It is timing, not the Kamelets. On the same commit, locally, these tests 
failed once and then passed four times in a row. The durations straddle the ten 
second period — the failing run was around twelve seconds, and passing runs 
have been observed at sixteen, twenty-three and twenty-five.
   
   I initially read the double fetch as a `camel-rest-openapi` behaviour change 
upstream, since these integrations run under Camel JBang against a moving 
snapshot. That was wrong, and I have corrected it on #3033: repeated runs on an 
unchanged tree show it is a race inside the test, not a component regression.
   
   ## Fix
   
   `timer-source` already exposes `repeatCount`, so the route now sends exactly 
one message, which is what the assertions actually describe:
   
   ```yaml
   parameters:
     repeatCount: 1
     period: 10000
   ```
   
   The period is left as it was. With a single firing it only delays the first 
message, and changing it would be noise.
   
   ## Verified
   
   Five consecutive runs of `OpenApiIT` pass:
   
   ```
   run 1: PASS  (add-pet 14628ms)
   run 2: PASS  (add-pet 23401ms)
   run 3: PASS  (add-pet 25529ms)
   run 4: PASS  (add-pet 18590ms)
   run 5: PASS  (add-pet 16174ms)
   ```
   
   Two of those took 23 and 25 seconds. Before this change a run that slow was 
exactly the case at risk of a second firing, so they are the interesting ones 
rather than the fast passes.
   
   One file, test resources only.
   
   ---
   _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]

Reply via email to