allthingssecurity commented on PR #28539:
URL: https://github.com/apache/camel/pull/28539#issuecomment-6438161202
@davsclaus thank you. All points are in 3a89405dddf1, one commit on top of
7f395d612a.
**Target → hooks.** A new subsection, "Target and hooks", with a table, in
the shape you suggested:
`endpoint=` and `component=` match the sends to the endpoint and the polls
of its consumer, `route=` matches the
route entry and the lifecycle, and `step=` matches the steps. A rule fires
at every hook of its target that offers its
fault. An optional `at=send|poll|entry|step` narrows it to one hook. A rule
is rejected when it is added, with an error
that names the hooks of the target, if its `at` is not a hook of the target,
or if no hook of the target (after `at`)
offers its fault. Your three examples:
- `endpoint=file:inbox* drop` or `error` fires at both the poll and the
send, unless `at=poll` or `at=send` narrows
it. With `corrupt` it fires at the sends only, as a poll does not offer
`corrupt`.
- `route=orders error` and `route=orders delay` are rejected. Route entry
offers only `corrupt`. `route=` does not
reach the sends and steps of the route; you target those with `endpoint=`,
`component=` or `step=`. Each hook has
one kind of target, so a rule and its counts in the report belong to one
kind of place.
- `component=kafka` matches the sends and the polls (a Kafka consumer does
not poll on a schedule, so in practice the
sends). It does not match route entry, which is `route=`.
The CLI examples are valid under the rule. One of them now shows `at=poll`.
**Seed.** The goal now reads "a seed fixes the random draws of the rules;
the same report again needs a DST world". The Time
section says that in real time with concurrent consumers, the threads decide
which exchange gets which draw. A DST world sets
`camel.chaos.seed` to `Dst.seed()` (from `@DstTest`, `@DstSeed` or
`-Ddst.seed`), or to a value of its own. camel-chaos
does not depend on camel-test-dst.
**Expectation still running.** An expectation is decided in two cases: when
its count is reached (met), or when
`within` has elapsed without it (unmet, FAIL). Before that it is "pending",
with the count so far and the time left,
and the verdict stays PASS. It also stays pending when the context stops
first (`reportOnShutdown`) or the rule is
removed first. A tool must treat pending as not yet decided.
**CLI shape.** Flat, to match `camel cmd` today: `camel cmd chaos-add`,
`chaos-change`, `chaos-remove` and
`chaos-clear`. The reads go under `camel get chaos`, which lists the rules,
or shows the report with `--report`. Each
command takes the integration name or pid first. `chaos-add` and
`chaos-change` must match exactly one integration,
as `camel cmd sql` does (`findOne`). The others may omit it and then act on
all, as `stop-route` does (`name = "*"`).
The examples include `myapp`. Rules get an id when they are added, and
change and remove take that id.
**Nits.**
- CLI and MCP are now the same six operations, `clear` included.
- The step hook row's Hook column is "Inside the error handler of the step
(CAMEL-26338)". The note about the
`disable-processor` check moved to the Faults column. The Summary names
CAMEL-26338.
- "...does nothing, unless `camel.chaos.enabled=true` is left there too."
Please confirm two decisions: `route=` does not cover the sends and steps of
its route, and `chaos-add`/`chaos-change`
require the integration name. A filter such as "the sends of route X" can
come later if anyone needs it.
The doc is now about 27 KB.
_Claude Code on behalf of allthingssecurity_
--
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]
