Andrea Cosentino created CAMEL-24919:
----------------------------------------
Summary: camel-debezium - the consumer health check has no startup
readiness signal
Key: CAMEL-24919
URL: https://issues.apache.org/jira/browse/CAMEL-24919
Project: Camel
Issue Type: Improvement
Components: camel-debezium
Reporter: Andrea Cosentino
h3. Summary
The Debezium consumer health check added by CAMEL-24889 reports {{UP}} from the
moment the route starts,
because it only knows about failures. It has no notion of "the connector is
actually consuming yet", so a
readiness probe green-lights the pod before the engine has connected.
h3. Details
{{ScheduledPollConsumerHealthCheck}} can honour
{{HealthCheckRegistry.getInitialState()}} - typically
{{DOWN}} - because {{ScheduledPollConsumer.isConsumerReady()}} flips after the
first successful poll, so
the check leaves {{DOWN}} on its own. {{DebeziumConsumer}} has no equivalent
signal, which is why
CAMEL-24889 deliberately did not adopt {{initialState}}: on the {{failure ==
null}} path it would pin the
route {{DOWN}} for its whole life.
The embedded engine does offer the signal, through the other callback on the
builder:
{code:java}
DebeziumEngine.create(Connect.class)
.using(...)
.using(connectorCallback) // connectorStarted / taskStarted /
pollingStarted
.notifying(this::onEventListener)
.build();
{code}
{{DebeziumEngine.ConnectorCallback}} has {{connectorStarted()}},
{{taskStarted()}} and
{{pollingStarted()}} (all default methods). Flipping a ready flag from
{{pollingStarted()}} - the point at
which {{AsyncEmbeddedEngine}} enters {{POLLING_TASKS}} - would let the health
check honour
{{initialState}} the way the scheduled-poll one does, so a route that is still
snapshotting or still
connecting reports {{DOWN}} to a readiness probe instead of {{UP}}.
This matters for the connectors whose initial snapshot can take minutes; today
the pod is declared ready
long before any change event can be delivered.
h3. Notes
Raised during the review of CAMEL-24889
(https://github.com/apache/camel/pull/26733) by both reviewers and
deliberately left out of that PR, which is scoped to failure detection. Whoever
picks this up should keep
the {{failure != null}} branch as it is and only change what the {{failure ==
null}} branch returns.
----
_Reported by Claude Code on behalf of oscerd (Andrea Cosentino)._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
