allthingssecurity opened a new pull request, #29291: URL: https://github.com/apache/camel/pull/29291
# Description [CAMEL-25980](https://issues.apache.org/jira/browse/CAMEL-25980) Follow-up of the reviews of #28036 (CAMEL-25729) and #28256 (CAMEL-25773): the late-event lookup of the aws-cloudtrail consumer (CAMEL-25727) for the secrets refresh task. `CloudTrailReloadTriggerTask` started each check at the newest event time it had seen. CloudTrail can make an event visible after a newer one, so an `UpdateSecret` or `PutSecretValue` event with an earlier time that became visible after a check saw a newer event was never read, and the secret's change did not reload the context (until the next update of that secret). Change (`CloudTrailReloadTriggerTask`, CloudTrail mode only; the SQS mode is unchanged): - The two lookups of a check (one per event name) start 10 minutes before the newest event seen, the default `lookBackWindow` of the aws-cloudtrail consumer, but not before the task started (an update made before the start still does not reload). - The ids of the events seen are kept with their event time and skipped when a later lookup returns them again; an id is forgotten once its event time is before the start of the next lookup. This replaces the ids kept for the events at exactly the newest time (they are a subset). - A late update of a secret does not move its time in `getUpdates()` back. Unlike the consumer, which runs a separate lookup of the last `lookBackWindow` before now every `lookBackInterval` (one page per poll, as its polls route the events), the task widens its two lookups: a check already reads every page, so no second lookup, interval or page state is needed. The window is anchored on the newest event seen, which is never after now, so it reads at least as far back as a window anchored on now: every update that CloudTrail makes visible within 10 minutes of its event time is read (CloudTrail delivers on average within about 5 minutes, not guaranteed). The task has no endpoint options, so the window is fixed rather than a new vault option. Cost: a check still sends two `LookupEvents` requests, plus one per further 50 events of one event name in the range it looks up, which is now up to 10 minutes longer. Only update events are read, so a second page needs more than 50 updates of one event name in about 10 minutes. A late update of a tracked secret reloads the context, also when a reload already happened after it (rare; the same as an update in the same second as the newest one seen today). The 4.24 upgrade-guide section of the refresh task (CAMEL-25729, unreleased) gets a paragraph. Tests (`CloudTrailReloadTriggerTaskLookupTest`, the fake `LookupEvents` answers like the service): - New: an update made visible after a newer event reloads the context, once; a late update does not move the update time back; the ids seen are forgotten once before the look-back, and the next lookups start 10 minutes before the newest event; an event exactly at the start of the next lookup is not seen twice (fails if the pruning bound is made inclusive). - Changed: two asserts on the start time of the next check (it is now 10 minutes before the newest event, but not before the task started). - Against main code (with the test helper ignoring the missing `startedAt` field): 5 of the 10 tests fail: the late-update test ("the late update must be seen"), the boundary test, the pruning test and the two changed start-time asserts; the other 5 pass (`lateUpdateDoesNotMoveTheUpdateTimeOfTheSecretBack` passes there by design, as main never reads the late update). With the change 20x: 200/200. camel-aws-secrets-manager unit tests (offline, `-DskipITs`): 27 run, 0 failures. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25980](https://issues.apache.org/jira/browse/CAMEL-25980). # Apache Camel coding standards and style - [x] 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 camel-aws-secrets-manager and the modules it depends on, including the formatter and import-sort plugins, and ran its unit tests. No generated file changes. I did not run the full root build.) # AI-assisted contributions - [x] 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](https://claude.com/claude-code) -- 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]
