[
https://issues.apache.org/jira/browse/CAMEL-26607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18140177#comment-18140177
]
Claus Ibsen commented on CAMEL-26607:
-------------------------------------
We walked the stage 2 ideas of the comment above, item by item. This is what
was decided.
h3. Before 4.24.0
*Multi-hook* (decided)
* {{ExtendedCamelContext}} gets {{addStepHook/removeStepHook}} and
{{addSendHook/removeSendHook}}. The single-slot setters go: they have not been
released yet.
* Inside, the context keeps one field: null, the one hook, or a copy-on-write
composite. The getters stay, so the hot path stays one null check.
* Hooks are sorted by {{Ordered}} ({{OrderedComparator}}, stable; no
{{Ordered}} = 0) when one is added. {{beforeStep}}/{{beforeSend}} run from low
to high, {{afterSend}} in reverse.
* The javadoc says: hooks that observe take a low order, hooks that change the
outcome a high one. Chaos is {{Ordered.LOWEST}}, the innermost hook, so a fault
looks like the processor itself failed, and observers still see the step.
* StepHook: a hook that throws fails the step, and the hooks after it are not
asked. The delays add up.
* SendHook: the first {{SKIP}} wins, and only the hooks whose {{beforeSend}}
ran get {{afterSend}}.
*P-1 {{duplicate}}* (keep, in 4.24.0)
* {{SendHook.SEND_TWICE = -2}}. {{SendHelper}} copies the message before the
first send and restores it for the second (resetting the stream cache). The
second send runs in the callback of the first, so one exchange is still on one
thread at a time.
* If the first send fails, there is no second one. With InOut, the second reply
wins. {{afterSend}} and the events happen once, and chaos counts the duplicate
in its report.
* With several hooks, {{SEND_TWICE}} from any of them makes two sends, and a
{{SKIP}} from an earlier hook still wins.
* Tests: InOnly twice, InOut, a failed first send, a stream body, a route with
{{idempotentConsumer}}.
h3. Stage 2
* *S2-1 errors at the route entry.*
** Only (b): {{route=X error|delay}} fails or delays the exchange at the first
step of the route, and the route's error handling applies.
** No {{at=consumer}}. A real consumer fault happens before an exchange exists,
and that differs per component. (a) was only "unhandled, back to the consumer",
which (b) already gives when the route does not handle the error.
** The guide says what the consumer sees in that case: a rollback, the file
left in place, an HTTP 500.
** True consumer faults stay {{at=poll}} (polling consumers) and
{{stall}}/{{lifecycle}} (the consumer is down). Consumer errors per component
(such as a Kafka poll error) are parked.
** {{drop}} at the entry: no.
* *S2-2 {{in=}}.*
** The name is {{in=}}. {{route=}} would clash with the entry faults of S2-1,
and {{scope=}} is vague.
** It means the route of the unit of work, not the routes it calls; use a
pattern ({{in=order*}}) for more. With {{at=poll}} it means the route whose
consumer polls.
** {{ChaosTargets.check}} warns when no route matches, or when the target
matches nothing inside those routes. The TUI form fills it in from the selected
route.
* *S2-3 {{when=}}.*
** The simple language only. A {{<language>:}} prefix is reserved for later,
and refused for now.
** The predicate is built once, and checked before {{fires(now)}}. It is not
allowed with {{at=poll}}, {{stall}} or {{lifecycle}}.
** The stream cache is reset after the check. A condition on the body is
refused when stream caching is off.
** A predicate that throws counts as not matched, and shows in
{{skippedReasons}}.
* *S2-4 + P-2*, one small PR.
** The integration name is optional for {{chaos-add/change/remove}}. With
exactly one integration running, it is used. With none or several, the command
fails with the list (exit 2). Add and change never mean "all".
** {{chaos-clear}} keeps its default {{*}}. The MCP tools follow the same rule.
** The hooks list shows {{poll}} only when a matching route's consumer is a
{{ScheduledPollConsumer}}, and {{send}} only when something sends to the target.
* *S2-5 AI with confirmation.*
** First {{ChaosRule.describe()}}, the rule in plain words. The confirmation,
the TUI table, the report and the dry-run use it. It goes early: {{in=}} and
{{when=}} each extend it.
** Then {{chaos-add --dry-run}} and the MCP tool {{camel_runtime_chaos_check}},
which say what the rule would hit.
** Then an eval set of 15-20 loose prompts, run with a small local model, after
S2-1..S2-3.
** Then a "describe the chaos you want" input on the chaos screen.
h3. Parked items
* P-3 the YAML form of the rules: dropped.
* P-4 a key per message (broker redeliveries): kept, for stage 3.
* P-5 a fault SPI: dropped, until someone asks for it.
h3. Wider ideas
* *W-1 scenarios*: {{chaos/<name>.chaos}} in the project, with one rule per
line, {{#}} comments and {{seed=}}. The phases come from {{from=}}/{{until=}}.
** {{camel cmd chaos-load <file>}}, {{camel run --chaos=<file>}}, and "save as
scenario" in the TUI.
** {{camel run *}} and {{camel export}} skip {{.chaos}} files.
* *W-2 CI mode*: PASS gives exit 0, FAIL exit 1. Without expectations there is
no verdict: exit 0, plus a line that says so. {{--chaos-report=<file>}} writes
the JSON report.
* W-3 chaos in tests, W-4 a test from a chaos run, W-5 a real error as a rule,
W-6 what to try (one rule set with the About screen hints, CAMEL-26700), W-7
what has been tried, W-8 expectations on time and loss: all kept.
* W-9 is built: the Timeline (CAMEL-26691). W-10 stays as planned in
CAMEL-26479.
h3. Order
# Before 4.24.0: multi-hook, then P-1 {{duplicate}}.
# S2-4 + P-2, and {{ChaosRule.describe()}}.
# S2-2 {{in=}}, then S2-1 errors at the entry.
# S2-3 {{when=}}.
# S2-5: dry-run and check, the eval set, the TUI input.
# W-1 + W-2, W-5, W-3 + W-4, W-8, then W-6 + W-7 with the hints.
_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)
