allthingssecurity opened a new pull request, #28256:
URL: https://github.com/apache/camel/pull/28256

   # Description
   
   [CAMEL-25773](https://issues.apache.org/jira/browse/CAMEL-25773)
   
   Follow-up to the review of CAMEL-25729 (#28036), the two points raised by 
gnodet-bot.
   
   The refresh task read the volatile field `lastTime` for every `LookupEvents` 
request. `doShutdown` sets `lastTime` to null, so a shutdown while a check 
reads its pages sent the next page without a start time (the whole event 
history of the last 90 days), and the two lookups of one check 
(`PutSecretValue` and `UpdateSecret`) could use different start times. The 
check now reads `lastTime` once and passes it to both lookups, so every page of 
both lookups uses the same start time; the newest event time is compared with 
that value too.
   
   The event loop also checked the event source and the event name of every 
event. The lookups are filtered by event name (`PutSecretValue` or 
`UpdateSecret`), so the event name check was always true and is removed. The 
event source check stays: event names are not unique across AWS services, as 
Claus noted on #28036, so it is not dead code (gnodet-bot's thread asked to 
remove both). The SQS notification path, whose messages are not filtered, keeps 
both checks.
   
   Tests:
   - New `everyPageOfBothLookupsOfOneCheckUsesTheSameStartTime` in 
`CloudTrailReloadTriggerTaskLookupTest`: the fake `LookupEvents` clears 
`lastTime` while the first page is read, as `doShutdown` does, and the test 
checks that the three requests of the check (two pages of `PutSecretValue`, one 
of `UpdateSecret`) all use the start time of the check. Without the change it 
fails with `expected: <2026-10-17T10:00:00Z> but was: <null>` (the second page 
is sent without a start time).
   - New `updateEventOfAnotherServiceIsIgnored`: an `UpdateSecret` event of 
another event source with the name of a tracked secret is not taken as an 
update (no reload), and still moves the start time of the next check. It passes 
on main too: it guards the event source check that stays.
   - camel-aws-secrets-manager unit tests: 12 run, 0 failures (formatter and 
import sort run in the same build).
   
   # 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).
   
   # 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 and tested camel-aws-secrets-manager, including the formatter and 
import-sort plugins. 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]

Reply via email to