shashank created CAMEL-25702:
--------------------------------
Summary: camel-ibm-secrets-manager - the secret refresh task stops
for good, without a log line, at the first IBM Event Streams record it cannot
read, so later secret rotations no longer reload the CamelContext
Key: CAMEL-25702
URL: https://issues.apache.org/jira/browse/CAMEL-25702
Project: Camel
Issue Type: Bug
Reporter: shashank
Assignee: shashank
With {{camel.vault.ibm.refreshEnabled=true}} Camel Main schedules
{{IBMEventStreamReloadTriggerTask}} through
{{PeriodTaskScheduler.scheduledTask}}: the task is submitted once and is
expected to run for as long as Camel runs. Its {{run()}} polls the IBM Event
Streams topic in a loop and reloads the CamelContext when a {{secret_rotated}}
event names a watched secret.
Nothing in the loop catches an exception (main d46d51c24550,
{{IBMEventStreamReloadTriggerTask.run()}} lines 175-226). Any record the task
cannot read ends it:
* a record value that is not JSON ({{JsonProcessingException}} is wrapped in a
{{RuntimeException}} and rethrown, line 188);
* a JSON record with {{data}} but without {{data.event_type}}
({{NullPointerException}}, line 192);
* a {{secret_rotated}} event without {{secrets}}, or a secret without
{{secret_name}} / {{event_time}} ({{NullPointerException}}).
The exception goes into the {{Future}} of the single-thread executor of the
period task scheduler, which nobody reads: nothing is logged, the CamelContext
keeps running, and from then on no secret rotation reloads it, so the routes
keep the old (rotated, possibly revoked) credentials. Only a restart of the
application brings the refresh back.
Trigger: the refresh feature with its documented configuration and one record
on the topic that does not have the shape the task expects (a test message, an
event of another source or type routed to the same topic, a schema change).
h3. Reproduction
New {{IBMEventStreamReloadTriggerTaskTest}} (no IBM services): the task is
started with a vault configuration (its {{doStart}} creates the Kafka consumer,
which never connects), the consumer is replaced by a scripted {{KafkaConsumer}}
subclass that returns one unreadable record and then a {{secret_rotated}} event
of a watched secret; a {{DefaultContextReloadStrategy}} subclass counts the
reloads. For each of the three unreadable records above, on main:
{noformat}
the rotation of a watched secret did not trigger a reload after the record [not
json] ==> expected: <true> but was: <false>
{noformat}
h3. Proposed fix
Each record is handled in its own {{try}}: a record that cannot be processed is
skipped with a WARN (offset, topic, cause) and the loop goes on with the next
one. A failure of {{KafkaConsumer.poll}} itself still ends the task, as before
(the Kafka client retries connection problems inside {{poll}}; what it throws
is an authentication, authorization or configuration error).
camel-ibm-secrets-manager unit tests with the fix: 6 run, 0 failures, 0
skipped. Not run: the integration tests (IBM Cloud), a real Event Streams topic.
How it was found: reading the vault refresh tasks that are scheduled once
({{scheduledTask}}: Kubernetes secrets, Kubernetes config maps, IBM) after the
Kubernetes tasks were fixed for the same "ends for good" shape; the test
confirmed it.
Affected: main (tested). camel-4.23.x, camel-4.22.x and camel-4.18.x have the
same loop (lines 180-192; read, not run).
Duplicate check (2026-10-16): JIRA text "IBMEventStreamReloadTriggerTask"
(CAMEL-24470, environment credentials), "ibm secrets manager" with "refresh"
(CAMEL-21905, CAMEL-21918, CAMEL-21920, CAMEL-25553); GitHub pull requests "ibm
secrets manager reload" (#25648, #27680, #25013; none about a failing record).
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
