davsclaus opened a new pull request, #29458: URL: https://github.com/apache/camel/pull/29458
## What [CAMEL-26765](https://issues.apache.org/jira/browse/CAMEL-26765): chaos sees through stub endpoints. This is the first step of [CAMEL-26760](https://issues.apache.org/jira/browse/CAMEL-26760) ("let there be chaos"), where an agent runs a project with `--stub=remote` and feeds the stubbed consumers with `camel cmd send`. ## Why The spike on CAMEL-26760 ran `camel run --stub=remote --chaos` with a Kafka consumer route and a timer route sending to Kafka, with no broker. Stubs, `camel cmd send` and the chaos rules worked, but: 1. `camel cmd chaos-suggest` said "Nothing to suggest: the routes call nothing remote": `StubEndpoint.isRemote()` is always false, and the suggestions go by `isRemote()`. 2. A route reading `kafka:refunds?breakOnFirstError=true` through a stub showed KEPT 0. `ChaosConsumers.keepsFailed` read the option through the configurer of the stub component, not Kafka's. The stub (a seda queue) also does not read a failed message again. So an exploration on stubs would report "failed, not kept" for a route that keeps its messages: a false finding. ## Changes - `ChaosStubs` (new): a stub that stands in for another component (the stub component behind a `kafka:` URI, known by its class name as camel-core knows it, so no dependency on camel-stub) counts as that component: - remote when the JSON of the component says so. `CatalogCamelContext.getComponentParameterJsonSchema` finds it through the factory finder when the component's JAR is on the classpath, and `camel run` downloads it for a stub too. Without the JAR, a stub stays not remote, as before. - its options read from its URI (any case), as the stub component does not configure them. Options set on the component do not count, as a stub does not take them. - `ChaosAdvisor` uses `ChaosStubs.isRemote` for the calls out and the input of a route. - `ChaosConsumers.keepsFailed` reads the options of a stub from its URI. - The report marks a route whose consumer is a stub: `stubbedConsumer` in the JSON, `(kept by the consumer 2, a stub of kafka that does not read them again)` in the text, `refunds (stub of kafka)` with a note line in `camel get chaos --report`, and `refunds (stub)` on the chaos screen of the TUI (the panel is narrow). - Docs: a "With stubs" section in the chaos doc, and `stubbedConsumer` in the JSON of the report (catalog copy regenerated). - Not in scope: making the stub consumer read a kept message again. ## Tests - `ChaosStubsTest` (new): a stub of a remote component (a fake `remotemq` with its JSON in the test resources) is remote, and the suggestions list a route error, a refused connection and a slow call for it; a plain `stub:` endpoint stands in for nothing; a stub of `kafka` with `breakOnFirstError=true` keeps 2 failed exchanges with `stubbedConsumer=kafka`, one without keeps none, and the text report says so. - `ListChaosTest.aRouteWhoseConsumerIsAStub`, and `ChaosTabRenderTest` checks `stock (stub)`. - Local runs, all passing: camel-chaos 807, camel-jbang-core `ListChaosTest` + `CamelChaos*Test`, TUI `Chaos*Test`. - End to end with the spike app (`camel run --stub=remote --chaos`): `chaos-suggest` now lists the refused connection, the slow call, the duplicate and the route error for the stubbed Kafka endpoints, and `camel get chaos --report` shows `refunds (stub of kafka)` with KEPT 2 for 2 failed messages. _Claude Code on behalf of Claus Ibsen_ -- 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]
