[
https://issues.apache.org/jira/browse/CAMEL-25773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shashank updated CAMEL-25773:
-----------------------------
Description:
Follow-up to the review of CAMEL-25729 (apache/camel#28036, merged), two points
raised by gnodet-bot on the PR.
{{CloudTrailReloadTriggerTask}} reads the volatile field {{lastTime}} for every
{{LookupEvents}} request. {{doShutdown}} sets {{lastTime}} to null, so a
shutdown while a check reads its pages sends 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}}) can use different start times.
The event loop also checks the event source and the event name of every event.
The lookups are filtered by event name, so the event name check is always true.
The event source check is not: event names are not unique across AWS services
(as noted on apache/camel#28036), so it stays.
*Change*: the check reads {{lastTime}} once and passes it to both lookups, so
every page of both lookups uses the same start time. The always-true event name
check is removed from the CloudTrail path and the event source check is kept;
the SQS notification path, whose messages are not filtered, keeps both.
Otherwise the behaviour is unchanged.
*Tests*: new
{{CloudTrailReloadTriggerTaskLookupTest.everyPageOfBothLookupsOfOneCheckUsesTheSameStartTime}}:
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}}) use the start time
of the check. It fails without the change: {{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 is not taken as an update of the secret (passes on main too; it
guards the kept check). camel-aws-secrets-manager unit tests: 12 run, 0
failures.
_Filed with Claude Code on behalf of allthingssecurity._
was:
Follow-up to the review of CAMEL-25729 (apache/camel#28036, merged), two points
raised by gnodet-bot on the PR.
{{CloudTrailReloadTriggerTask}} reads the volatile field {{lastTime}} for every
{{LookupEvents}} request. {{doShutdown}} sets {{lastTime}} to null, so a
shutdown while a check reads its pages sends 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}}) can use different start times.
The event loop also checks the event source and the event name of every event.
The lookups are filtered by event name, so both checks are always true; they
suggest the results could hold other events.
*Change*: the check reads {{lastTime}} once and passes it to both lookups, so
every page of both lookups uses the same start time. The always-true checks are
removed from the CloudTrail path; the SQS notification path, whose messages are
not filtered, keeps them. Otherwise the behaviour is unchanged.
*Tests*: new
{{CloudTrailReloadTriggerTaskLookupTest.everyPageOfBothLookupsOfOneCheckUsesTheSameStartTime}}:
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}}) use the start time
of the check. It fails without the change: {{expected: <2026-10-17T10:00:00Z>
but was: <null>}} (the second page is sent without a start time).
camel-aws-secrets-manager unit tests: 11 run, 0 failures.
_Filed with Claude Code on behalf of allthingssecurity._
> camel-aws-secrets-manager - the CloudTrail refresh task reads lastTime for
> every lookup page, so a shutdown during a check sends the next page without a
> start time
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25773
> URL: https://issues.apache.org/jira/browse/CAMEL-25773
> Project: Camel
> Issue Type: Improvement
> Components: camel-aws2
> Reporter: shashank
> Assignee: shashank
> Priority: Minor
>
> Follow-up to the review of CAMEL-25729 (apache/camel#28036, merged), two
> points raised by gnodet-bot on the PR.
> {{CloudTrailReloadTriggerTask}} reads the volatile field {{lastTime}} for
> every {{LookupEvents}} request. {{doShutdown}} sets {{lastTime}} to null, so
> a shutdown while a check reads its pages sends 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}}) can use different start
> times.
> The event loop also checks the event source and the event name of every
> event. The lookups are filtered by event name, so the event name check is
> always true. The event source check is not: event names are not unique across
> AWS services (as noted on apache/camel#28036), so it stays.
> *Change*: the check reads {{lastTime}} once and passes it to both lookups, so
> every page of both lookups uses the same start time. The always-true event
> name check is removed from the CloudTrail path and the event source check is
> kept; the SQS notification path, whose messages are not filtered, keeps both.
> Otherwise the behaviour is unchanged.
> *Tests*: new
> {{CloudTrailReloadTriggerTaskLookupTest.everyPageOfBothLookupsOfOneCheckUsesTheSameStartTime}}:
> 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}}) use the
> start time of the check. It fails without the change: {{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 is not taken as an update of
> the secret (passes on main too; it guards the kept check).
> camel-aws-secrets-manager unit tests: 12 run, 0 failures.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
