Claus Ibsen created CAMEL-26607:
-----------------------------------
Summary: camel-chaos - stage 2: more flexible rules and conditions
(errors at the route entry, a when= condition on the message, loose prompts
through AI)
Key: CAMEL-26607
URL: https://issues.apache.org/jira/browse/CAMEL-26607
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Reporter: Claus Ibsen
Fix For: 4.24.0
Stage 2 of camel-chaos (stage 1 is CAMEL-26330 and its follow-ups, all in
4.24.0; design in {{design/chaos.adoc}}).
Stage 1 puts chaos at a specific place: an endpoint, a step, a node, a poll, a
route entry or the route lifecycle. Stage 2 makes the rules more flexible, so
that a person can prompt loosely and the AI ({{camel ask}}, the camel-jbang MCP
server) works out the rules. For example:
{quote}the order route should have chaos, by failing 5% or when a message
origin country is spain{quote}
Against stage 1 this prompt hits two gaps:
# *An error at the route entry.* {{route=orders error}} is rejected today: the
route entry offers only {{corrupt}}, and {{route=}} matches the route entry and
the lifecycle only, not the sends and steps of the route.
# *A content condition.* A rule fires by {{rate}} (a probability or
{{every:N}}) only. There is no condition on the message, such as
{{when=<predicate>}} on a header or the body (origin country is Spain).
The "or" in the prompt can stay two rules (one with {{rate=0.05}}, one with
{{when=...}} and no rate).
Scope (to decide after the hands-on round):
* Errors (and possibly other faults) at the route entry.
* A filter for "the sends or steps of route X", so that a rule can target
everything a route does.
* A {{when=}} condition on the message, evaluated only in dev mode as the rest
of chaos.
* Omit the integration name in {{chaos-add}}/{{chaos-change}} when only one
integration runs.
* Check that the AI tools can turn loose prompts like the one above into rules,
and show the rules for confirmation before adding them (as {{camel ask}} does
today).
Other candidates from the design, not committed: a YAML form of the rules,
tying attempts of the same message by a key in the report (file name,
JMSMessageID, Kafka offset), custom fault types through a plugin SPI.
Before this starts: try stage 1 hands-on from the CLI, an AI and the terminal
UI, and collect what is intuitive and what is not. Those findings feed into
this ticket.
Chaos must keep working together with the other dev features (debugger, tracer,
the proposed exchange sanitizer and so on), see the single {{StepHook}} slot of
CAMEL-26338.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
