[
https://issues.apache.org/jira/browse/CAMEL-26607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139685#comment-18139685
]
Claus Ibsen commented on CAMEL-26607:
-------------------------------------
>From the hands-on round (CAMEL-26667, resolved), two points for stage 2:
* the {{duplicate}} fault ({{endpoint=kafka:orders* duplicate}}: send the
message twice, to test an idempotent consumer), which needs a "send again"
result in the SendHook SPI;
* a small one: a rule on an endpoint lists the hooks its target offers
({{hooks: ["send","poll"]}} for {{direct:}}, which has no polls), not the ones
that apply to the matching endpoints.
For an AI that turns loose prompts into rules: the rule model in the catalog
(CAMEL-26689, {{CamelCatalog.chaosModelJSon()}}) has the vocabulary of the
rules and the recipes.
_Claude Code on behalf of Claus Ibsen_
> 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
> Priority: Major
> 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)
