[allthingssecurity]

Description

CAMEL-26948, part of CAMEL-26610.

A deterministic simulation test (camel-test-dst) of the camel-aws2-kinesis consumer, in the dst package of its tests, in the same form as the SQS world: KinesisConsumerDstTest (1000 seeds), KinesisWorld and FakeKinesis. Test only; no main code changes.

What the world models: the real consumer (Kinesis2Consumer, its shard monitor and the resume strategy) and Camel's routing run on the virtual-time loop; only Kinesis is faked, as a KinesisClient bound as amazonKinesisClient. The fake is written from the API reference of GetShardIterator, GetRecords, ListShards, SplitShard and MergeShards and cites it: shard iterators are positions valid for five minutes (ExpiredIteratorException after that), the iterator types, answers with fewer records than the limit, a closed shard whose last GetRecords returns no next iterator and lists its child shards, and paginated ListShards.

The seed picks the iterator type (TRIM_HORIZON, LATEST), whether the route checkpoints with the resumable EIP and KinesisResumeStrategy (the resume cache outlives the consumer, so a restarted route resumes from it), the number of shards, maxResultsPerRequest, the poll delay, the shard monitor interval and shardClosed (ignore, silent), and injects failed GetRecords, GetShardIterator and ListShards calls, slow answers, slow and failed processing (now and then longer than an iterator is valid), route restarts, suspensions of up to eight minutes (the cached iterators expire) and splits and merges of shards.

Invariants: a consumer routes each record at most once (apart from a record after its checkpoint whose processing failed, which the resume strategy reads again); a restarted route resumes after its checkpoint; once the faults cleared every record is routed and the checkpoint of each open shard reaches its last record; the consumer uses the API as documented. A record stored before the consumer started a shard of its first shard list with LATEST, and without a checkpoint, is skipped by design.

With LATEST, when the iterator of a shard from which the consumer has not routed a record yet expires, the consumer asks for LATEST again, which skips the records stored meanwhile. The default set accepts this only right after such an expiry; -Ddst.kinesis.strictLatest=true counts those records as missing, and then 44 of 2000 seeds on main fail. This is CAMEL-26968 (records stored while a route is suspended for more than five minutes are lost); the world names it in its Javadoc, in the comment of FakeKinesis.getShardIterator and in the issues of @DstWorld.

Limits, written in the world's Javadoc: the JIRA item "a stop while a poll runs" is not driven. On the one stack of the harness a graceful shutdown cannot see a poll below it finish, so the operator suspends the consumer first (as the shutdown strategy does) and stops or suspends the route only between polls; that item of CAMEL-26948 stays open. Not explored: the KCL consumer, the asynchronous client, a configured shardId, and AT_SEQUENCE_NUMBER, AFTER_SEQUENCE_NUMBER and AT_TIMESTAMP as the configured iterator type. Not modelled: retention, hash key ranges, enhanced fan-out, read limits beyond the injected throttling, the expiry of a NextToken, shards that close between two pages of a listing, and a stream deleted and created again.

Other changes:

• camel-test-dst as a test dependency of camel-aws2-kinesis, and its byte code agent on the surefire command line, as for the other worlds.
• The test log of camel-aws2-kinesis goes to a size-capped rolling file (50 MB, one backup), as a failing world can log a lot.
• The "Running the tests" section of the camel-test-dst page lists the Kinesis module, its self-check commits (043ac9e, 847ee9a) and dst.kinesis.strictLatest.
• The @DstWorld annotation lists the world in the component JSON (and its catalog copy) and in the table of the camel-test-dst page (and its catalog copy, byte-identical).

Tests:

• On main: 5000 of 5000 seeds pass (about 9 ms a seed). Seeds 8 and 77 replayed in two JVMs give the same trace hashes.
• Self-check against fixed bugs: on the code before CAMEL-25569 (043ac9e reverted) 305 of 2000 seeds fail (expired iterators and child shards read with LATEST); on the code before CAMEL-25942 (847ee9a reverted) 710 of 2000 seeds fail, all of them seeds with checkpoints. CAMEL-25558, in the JIRA's list of candidates, is a camel-aws2-s3 fix and is not used.
• The Kinesis unit tests of the module (org.apache.camel.component.aws2.kinesis): 1063 run (63, plus 1000 seeds), 0 failures, 0 errors, 0 skipped. The Firehose tests of the same module were not run.
• After the review follow-up (one invariant name, CAMEL-26968, the second-routing excuse keyed on a recorded processing failure): again 5000 of 5000 seeds pass on main, the module's Kinesis tests pass (1063), and the self-check gives the same counts (305 and 710 of 2000).

What was not run locally: the ITs (they need Docker) and the full root build. I built and tested offline with the versions cached on my machine: AWS SDK 2.55.15 and the Kinesis client library 3.5.3 (main has 2.57.11 and 3.5.4), commons-lang3 3.21.0 and Guava 33.7.2 (main has 3.22.0 and 33.8.0-jre).

Target

• I checked that the commit is targeting the correct branch (Camel 4 uses the main branch)

Tracking

• If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it): CAMEL-26948.

Apache Camel coding standards and style

• I checked that each commit in the pull request has a meaningful subject line and body.
• I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.
  (I built and tested camel-test-dst, camel-aws-common and camel-aws2-kinesis, including the formatter and import-sort plugins. The generated files touched are the component JSON with its catalog copy, and the table of the camel-test-dst page with its catalog copy, which is byte-identical to the page. I did not run the full root build.)

AI-assisted contributions

• If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., Co-authored-by trailers) and the PR description identifies the AI tool used.
  This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a Co-Authored-By trailer.

Claude Code on behalf of allthingssecurity

🤖 Generated with Claude Code

[gnodet]

Review: Kinesis Consumer DST Harness

APPROVE — Comprehensive, well-designed DST (deterministic simulation testing) harness for the Kinesis consumer. The FakeKinesis API model is faithful to the AWS reference, the invariant checker is sound across all investigated edge cases (epoch boundaries, LATEST skip accumulation, checkpoint resume, listing pagination), and the single-event-loop model eliminates concurrency concerns in the fake.

Two low-severity documentation suggestions:

1. FakeKinesis.java — "Not modelled" Javadoc omits AT_TIMESTAMP

The "Not modelled" paragraph at lines 63–67 lists many excluded behaviours but does not mention AT_TIMESTAMP, which is modelled (handled in the getShardIterator switch at line 279). The comment as written implies AT_TIMESTAMP is excluded along with the rest.

Suggest adding a note such as:

 * (AT_TIMESTAMP is modelled in getShardIterator but not exercised by KinesisWorld)

2. KinesisWorld.java line 548 — comparator style

// current
keys.sort((a, b) -> a.toString().compareTo(b.toString()));

// more idiomatic
keys.sort(Comparator.comparing(Object::toString));

Both suggestions are nits; they do not affect correctness. The core test logic is solid.

---

Category: test | Labels: [test] | Backport: not applicable | LTS candidate: no

[davsclaus]

Thanks @allthingssecurity, a careful world. The fake cites GetShardIterator, GetRecords and ListShards for each rule, reads take effect after their round trip, the seed picks the configuration, the drain is a finisher with a deadline, and the pom change is test scope only, as in aws2-sqs. The self-check against 043ac9e (CAMEL-25569) and 847ee9a (CAMEL-25942) is the right kind of evidence. I agree with gnodet's notes and won't repeat them.

Two things I'd like changed before merge:

1. The invariant names do not match. KinesisWorld.java:103 lists "every record is routed once the faults cleared, apart from records skipped by a LATEST iterator", but dst.check at KinesisWorld.java:202 names it "every record is routed once the faults cleared". The guide (step 10) asks for the names used in dst.check(...), and as it stands the catalog JSON shows a name that never appears in a failure report. Please use one string in both places and regenerate aws2-kinesis.json and its catalog copy.
2. Please link the LATEST excuse to CAMEL-26968. The default set excuses the records a new LATEST iterator skips after an expiry (KinesisWorld.java:76-80, FakeKinesis.java:256-265); the PR body says no JIRA was opened, but CAMEL-26968 now tracks exactly this. Please name it in the Javadoc and the comment at FakeKinesis.java:256, add it to issues of @DstWorld (as the SQS world does with CAMEL-25737), and update the PR body. I do think it is a real bug: records stored while a route is suspended for more than 5 minutes are lost.

Smaller, optional:

• KinesisWorld.java:226-227 excuses a second routing whenever r.completed == 0. The guide asks that only the injected fault excuses a violation, so keying it on a recorded failure (a failed count on Rec, as the Kafka world has) would be tighter.
• The Javadoc of finisher (KinesisWorld.java:320-323) says it "stops the route", but the code only sets finished and leaves the stop to context.stop() (see the comment at :359).
• The "Running the tests" section of test-dst.adoc could list components/camel-aws/camel-aws2-kinesis in -pl and the commits 043ac9e / 847ee9a, to keep the self-check repeatable.

Note: GitHub has not started any CI run on this PR yet; it needs one before merge (the author built against an older AWS SDK and KCL than main has).

Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• catalog/camel-catalog
• components/camel-aws/camel-aws2-kinesis
• components/camel-test/camel-test-dst

🔁 3 tests passed only after a retry on JDK 21 (3 retried attempts)

Recovered flaky tests on JDK 21 (3)

Module	Test	Failed attempts	First failure
dsl/camel-jbang/camel-jbang-core	ExportApiTest.repeatedExportsReleaseTheirSilentRuns	1	java.io.FileNotFoundException: ./application.properties (No such file or directory)
dsl/camel-jbang/camel-jbang-plugin-tui	AiPanelAcpTest.usageUpdateFeedsTheTokenCounter	1	array contents differ at index [0], expected: <900> but was: <0>
dsl/camel-jbang/camel-jbang-plugin-tui	ArchitectureViewTest.showsGroupsWithTheirFacts	1	the first group is selected ==> expected: <group:billing> but was: <null>

ℹ️ These tests did not fail the build. Surefire retried them and they passed.
Retries are enabled project-wide by surefire.rerunFailingTestsCount in parent/pom.xml.

---

🔬 Scalpel shadow comparison — Scalpel: 20 of 726 tested, 3 compile-only — current: 20 all tested

Maveniverse Scalpel detected 20 affected modules (current approach: 20).

Skip-tests mode would test 20 modules (3 direct + 0 downstream), skip tests for 3 (generated code, meta-modules)

Modules Scalpel would test (20)

• camel-aws2-eventbridge ← depends on affected reactor module org.apache.camel:camel-aws2-sqs
• camel-aws2-kinesis ← components/camel-aws/camel-aws2-kinesis/src/generated/resources/META-INF/org/apache/camel/component/aws2/kinesis/aws2-kinesis.json, components/camel-aws/camel-aws2-kinesis/src/test/java/org/apache/camel/component/aws2/kinesis/dst/FakeKinesis.java, components/camel-aws/camel-aws2-kinesis/src/test/java/org/apache/camel/component/aws2/kinesis/dst/KinesisConsumerDstTest.java, components/camel-aws/camel-aws2-kinesis/src/test/java/org/apache/camel/component/aws2/kinesis/dst/KinesisWorld.java, components/camel-aws/camel-aws2-kinesis/src/test/resources/log4j2.properties, own pom components/camel-aws/camel-aws2-kinesis/pom.xml changed
• camel-aws2-sqs ← depends on affected reactor module org.apache.camel:camel-test-dst
• camel-azure-eventhubs ← depends on affected reactor module org.apache.camel:camel-test-dst
• camel-chaos ← depends on affected reactor module org.apache.camel:camel-test-dst
• camel-cli-connector ← depends on affected reactor module org.apache.camel:camel-chaos
• camel-cli-debug ← depends on affected reactor module org.apache.camel:camel-cli-connector
• camel-google-pubsub ← depends on affected reactor module org.apache.camel:camel-test-dst
• camel-jbang-mcp ← depends on affected reactor module org.apache.camel:camel-chaos
• camel-jbang-plugin-mcp ← depends on affected reactor module org.apache.camel:camel-jbang-core
• camel-jbang-plugin-tui ← depends on affected reactor module org.apache.camel:camel-chaos
• camel-jbang-plugin-validate ← depends on affected reactor module org.apache.camel:camel-jbang-core
• camel-jbang-run ← depends on affected reactor module org.apache.camel:camel-catalog
• camel-kafka-share ← depends on affected reactor module org.apache.camel:camel-test-dst
• camel-launcher-container ← depends on affected reactor module org.apache.camel:camel-launcher
• camel-pulsar ← depends on affected reactor module org.apache.camel:camel-test-dst
• camel-slack ← depends on affected reactor module org.apache.camel:camel-test-dst
• camel-test-dst ← components/camel-test/camel-test-dst/src/main/docs/test-dst.adoc
• camel-yaml-dsl-validator ← depends on affected reactor module org.apache.camel:camel-catalog
• camel-yaml-dsl-validator-maven-plugin ← depends on affected reactor module org.apache.camel:camel-yaml-dsl-validator

Modules with tests skipped (3)

• camel-itest
• camel-yaml-dsl
• camel-yaml-dsl-deserializers

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

All tested modules (47 modules, 9m 51s total)

Total reactor time: 9m 51s

Module	Duration	Status
Camel :: AWS2 Kinesis	59.7s	SUCCESS
Camel :: Component DSL	59.5s	SUCCESS
Camel :: JBang :: MCP	59.1s	SUCCESS
Camel :: Slack	47.0s	SUCCESS
Camel :: Kafka :: Share	46.2s	SUCCESS
Camel :: Docs	38.5s	SUCCESS
Camel :: YAML DSL :: Validator	32.5s	SUCCESS
Camel :: Catalog :: Camel Report Maven Plugin	25.6s	SUCCESS
Camel :: JBang :: Plugin :: Validate	25.3s	SUCCESS
Camel :: JBang :: Plugin :: Kubernetes	23.6s	SUCCESS
Camel :: JBang :: Run	21.6s	SUCCESS
Camel :: Catalog :: Camel Catalog	20.1s	SUCCESS
Camel :: YAML DSL	19.3s	SUCCESS
Camel :: AWS2 Eventbridge	18.3s	SUCCESS
Camel :: JBang :: Plugin :: Testing	13.5s	SUCCESS
Camel :: Kamelet Main	11.6s	SUCCESS
Camel :: Test :: DST	10.5s	SUCCESS
Camel :: JBang :: Plugin :: Generate	8.3s	SUCCESS
Camel :: Catalog :: Suggest (deprecated)	7.9s	SUCCESS
Camel :: Catalog :: Camel Route Parser	7.5s	SUCCESS
Camel :: All Components Sync point	5.7s	SUCCESS
Camel :: YAML DSL :: Deserializers	5.4s	SUCCESS
Camel :: YAML DSL :: Validator Maven Plugin	3.3s	SUCCESS
Camel :: Catalog :: Maven	3.0s	SUCCESS
Camel :: Endpoint DSL :: Support	2.8s	SUCCESS
Camel :: Coverage	2.1s	SUCCESS
Camel :: DSL :: CLI Debug	2.0s	SUCCESS
Camel :: JBang :: Plugin :: MCP	1.8s	SUCCESS
Camel :: Assembly	1.8s	SUCCESS
Camel :: YAML DSL :: Maven Plugins	1.7s	SUCCESS
Camel :: JBang :: Plugin :: Edit	1.6s	SUCCESS
Camel :: JBang :: Main	1.5s	SUCCESS
Camel :: JBang :: Integration tests	1.2s	SUCCESS
Camel :: Catalog :: Dummy Component	0.8s	SUCCESS
Camel :: Catalog :: Console	0.6s	SUCCESS
Camel :: Launcher :: Container	0.6s	SUCCESS
Camel :: AWS2 SQS	n/a
Camel :: Azure :: Event Hubs	n/a
Camel :: Chaos	n/a
Camel :: DSL :: CLI Connector	n/a
Camel :: Endpoint DSL	n/a
Camel :: Google :: PubSub	n/a
Camel :: Integration Tests	n/a
Camel :: JBang :: Core	n/a
Camel :: JBang :: Plugin :: TUI	n/a
Camel :: Launcher	n/a
Camel :: Pulsar	n/a

Top 20 slowest modules:

• Camel :: AWS2 Kinesis (59.7s)
• Camel :: Component DSL (59.5s)
• Camel :: JBang :: MCP (59.1s)
• Camel :: Slack (47.0s)
• Camel :: Kafka :: Share (46.2s)
• Camel :: Docs (38.5s)
• Camel :: YAML DSL :: Validator (32.5s)
• Camel :: Catalog :: Camel Report Maven Plugin (25.6s)
• Camel :: JBang :: Plugin :: Validate (25.3s)
• Camel :: JBang :: Plugin :: Kubernetes (23.6s)
• Camel :: JBang :: Run (21.6s)
• Camel :: Catalog :: Camel Catalog (20.1s)
• Camel :: YAML DSL (19.3s)
• Camel :: AWS2 Eventbridge (18.3s)
• Camel :: JBang :: Plugin :: Testing (13.5s)
• Camel :: Kamelet Main (11.6s)
• Camel :: Test :: DST (10.5s)
• Camel :: JBang :: Plugin :: Generate (8.3s)
• Camel :: Catalog :: Suggest (deprecated) (7.9s)
• Camel :: Catalog :: Camel Route Parser (7.5s)

---

⚙️ View full build and test results

[allthingssecurity]

Thanks @davsclaus (and gnodet for the two notes). Pushed d106111 on top of your rebase:

1. Invariant name: dst.check now uses the same string as @DstWorld, "every record is routed once the faults cleared, apart from records skipped by a LATEST iterator". The component JSON and its catalog copy already carried that name; they are regenerated for the issues change below and are byte-identical.
2. CAMEL-26968: named in the world Javadoc (the paragraph on the excused LATEST skip), in the comment in FakeKinesis.getShardIterator, and in issues of @DstWorld (CAMEL-25569, CAMEL-25942, CAMEL-26968), so the catalog JSON and the table of the camel-test-dst page (and its catalog copy) list it too. The PR body now links it.

Optional points:

• Second routing keyed on a recorded failure: done. Rec has a failed count, set where the injected processing failure is thrown, and the excuse for a second routing after the checkpoint needs r.failed > 0 && r.completed == 0, as in the Kafka world.
• finisher Javadoc: done; it says the finisher only sets finished and that the run then stops the CamelContext.
• test-dst.adoc, "Running the tests": done; KINESIS=components/camel-aws/camel-aws2-kinesis is in the -pl lists, the self-check commits 043ac9e (CAMEL-25569) and 847ee9a (CAMEL-25942) are listed with the other worlds' past fixes, and dst.kinesis.strictLatest with the world-specific properties.

From gnodet's review: the "Not modelled" paragraph of FakeKinesis now says AT_TIMESTAMP is modelled in GetShardIterator but not configured by the world, and the resume cache sorts its keys with Comparator.comparing(Object::toString).

Tests on the new head:

• the Kinesis tests of the module: 1063 run (63, plus 1000 seeds), 0 failures;
• 5000 seeds: 0 failing;
• self-check: with the main code of 043ac9e (CAMEL-25569) reverted 305 of 2000 seeds fail, with the main code of 847ee9a (CAMEL-25942) reverted 710 of 2000 fail, as before the change (so keying the excuse on a recorded failure did not hide anything, and did not make main fail).

Claude Code on behalf of allthingssecurity

[davsclaus]

Thanks @allthingssecurity, d106111 covers both requested changes and the optional points:

1. dst.check and @DstWorld now use the same invariant name: "every record is routed once the faults cleared, apart from records skipped by a LATEST iterator".
2. CAMEL-26968 is named in the world Javadoc, in the comment in FakeKinesis.getShardIterator and in issues of @DstWorld, and the JSON and test-dst.adoc copies are regenerated.

The excuse for routing a record a second time after the checkpoint now needs r.failed > 0 && r.completed == 0, and failed counts only where the injected processing failure is thrown. That is tighter, and the self-check numbers did not change (305 and 710 of 2000), so it hid nothing. The finisher Javadoc and the "Running the tests" section are fixed too, and gnodet's two nits are in. Looks good to me.

Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.

[gnodet-bot]

Previous findings are all addressed. LGTM.

What the new commit covers:

• FakeKinesis.java — "Not modelled" Javadoc now explicitly notes that AT_TIMESTAMP is modelled in getShardIterator but not configured by KinesisWorld (gnodet's nit addressed)
• MapResumeCache.forEach — Comparator.comparing(Object::toString) replaces the hand-written lambda (gnodet's nit addressed)
• KinesisWorld.java — invariant name in dst.check now matches @DstWorld exactly; CAMEL-26968 named in Javadoc, comment, and issues=; second-routing excuse tightened to r.failed > 0 && r.completed == 0; finisher Javadoc corrected; test-dst.adoc updated with Kinesis module and self-check commits (all davsclaus items)

Category: test | Backport: not applicable | LTS candidate: no

This review was generated by an AI agent, Hermès on behalf of @gnodet.