davsclaus opened a new pull request, #29322: URL: https://github.com/apache/camel/pull/29322
_Claude Code on behalf of Claus Ibsen_ [CAMEL-26679](https://issues.apache.org/jira/browse/CAMEL-26679), part of CAMEL-26667 (the findings of the hands-on round of camel-chaos stage 1). New faults for camel-chaos. They need no new API: the send hook's `afterSend` can already set an exception and change the reply. | Rule | What it does | |---|---| | `endpoint=https:payments* error status=503 at=reply` | Fails the send **after** the producer succeeded, so the side effect has already happened and a redelivery sends it again (tests duplicates). `at=reply` offers `error` (also `status=`) and `corrupt` (the reply). It is reached only with `at=reply`, like `at=dlq`. | | `endpoint=kafka:orders* error after=5s exception=java.net.SocketTimeoutException` | A timeout: waits on the sending thread (step and poll threads too), then fails without calling the producer. Not offered `at=reply`, because the reply can run on an I/O thread. | | `step=enrich delay duration=100ms..2s` | A jittered delay, drawn from the rule's seeded sequence, so a seed gives the same delays again. | | `endpoint=seda:shipping* drop from=+30s until=1m` | Starts 30s after it is added, so faults begin after warm-up. Until then the state is `waiting`; its `until` time counts from the start. Also works for `stall`/`lifecycle`. | | `endpoint=kafka:orders* error rate=burst:5s/30s` | Outage windows: every match fires during the first 5s of each 30s, none in between. | | `route=orders stall duration=10s repeat=3 every=1m` | A flapping route: down three times, each a minute after the last. `every` must be longer than `duration`, and the whole run must fit in `camel.chaos.maxDuration`; `repeat` is at most 100. Removing the rule between rounds ends it. | | `corrupt mode=empty`, `mode=remove-header header=X-Trace-*` | `empty` empties the body: an empty String, no bytes, or an empty stream; any other body becomes null. `remove-header` removes the named headers (a name or a `*` pattern, ignoring case), or without `header=` every non-`Camel*` header. | | `corrupt mode=truncate` | Now also cuts String and `byte[]` bodies in half (these were skipped before). | The `duplicate` fault stays in stage 2 (CAMEL-26607): it needs a "send again" result in the SendHook SPI. ### Report, dev console, `camel get chaos`, MCP - Rule state `waiting` with `startsIn`. A burst rule has `burstEndsIn` / `nextBurstIn` and text like `rate 15% of 5s in 30s, next burst in 12s`. - A lifecycle rule has `round`, `repeat`, `every` and `actsIn`, and text like `round 1 of 3: suspended route orders at +2ms, resumed at +10s5ms (down 10s3ms); round 2 in 49s`. `fired.lifecycle` counts the rounds. - Fault texts in the recent faults: `error SocketTimeoutException after 5s`, `delay 100ms..2s`, `corrupt remove-header x-trace-*`. - `camel get chaos` NOTE column: `starts in 25s`, `next burst in 12s`, `route poller pending (round 1 of 3), acts in 40s`. - The dev console JSON descriptions, the catalog copies (including `dev-consoles-openapi.json`) and the MCP `chaos_list` description are updated. ### How a reply fault knows the producer ran `afterSend` is asked only when the send has no exception, is not the send of the dead letter channel, and was not skipped by chaos. For the skip, `beforeSend` marks the exchange state when it returns `SKIP`. `afterSend` comes right away in that case, with no other send of the exchange in between, so it clears the mark and returns. ### Tests - camel-chaos: 628 tests, all pass. New: `ChaosReplyFaultsTest` (the duplicate payment through redelivery, a corrupt reply, no reply after a drop or a failed producer), `ChaosTimingFaultsTest` (FakeClock: a timeout at a send, a step and a poll; jitter; `from=`; bursts), plus lifecycle `repeat=`/`from=`, corrupt modes and parser cases. - camel-jbang-core: `ListChaosTest` (the new notes), `CliHelpGoldenTest` and `CamelChaosActionTest` pass; camel-jbang-mcp compiles. - Hands-on: `camel run --chaos` with the branch jars, rules added through `camel cmd chaos-add`, passes 55 of 55 checks (the 43 from before plus 12 new): ``` new faults: error at the reply, a timeout, a jittered delay, from=, bursts, a flapping route, corrupt modes (CAMEL-26679) ok error at the reply fired 4 times (4) ok the first order went to the DLQ, the second recovered ((1, 1)) ok the stock route ran again for the redeliveries (True) ok a timeout after 1s (error status 504 after 1s) ok a jittered delay fired 5 times (5) ok its fault (delay 10ms..200ms) ok from=: waiting (waiting) ok camel get chaos says when it starts ok from=: ended after it fired (('ended', True)) ok bursts: about a third of the matches (True) ok a flapping route: 3 rounds, back ((3, 'back')) ok truncate a String body, remove a header, empty the body ([1, 1, 1]) ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_012nJsFsjqqFiwroeHRWaKbS -- 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]
