shashank created CAMEL-25725:
--------------------------------
Summary: camel-iggy - messageExpiry is documented in seconds but
passed to Iggy unchanged, which reads it in microseconds, so a topic created by
Camel expires its messages a million times too early
Key: CAMEL-25725
URL: https://issues.apache.org/jira/browse/CAMEL-25725
Project: Camel
Issue Type: Bug
Reporter: shashank
Assignee: shashank
The {{messageExpiry}} option of camel-iggy is documented as "Message expiry
time in seconds (0 means no expiry)". {{IggyEndpoint.initializeTopic}} (main
e339a2e9019f) creates the topic, when it does not exist and
{{autoCreateTopic=true}} (the default), with:
{code:java}
client.topics().createTopic(StreamId.of(stream),
iggyConfiguration.getPartitionsCount(),
iggyConfiguration.getCompressionAlgorithm(),
BigInteger.valueOf(iggyConfiguration.getMessageExpiry()),
BigInteger.valueOf(iggyConfiguration.getMaxTopicSize()),
topic,
options);
{code}
The Iggy Java client (0.9.0, {{TopicsTcpClient.createTopicOptions}}) sends the
value unchanged as the u64 option {{message_expiry}}, and the server converts
it with {{IggyExpiry::from(u64)}} = {{IggyDuration::from(value)}} =
{{Duration::from_micros(value)}} (apache/iggy
{{core/common/src/utils/expiry.rs}} and {{duration.rs}}; the topic option key
is documented as "{{Uint64}} micros or a humantime string" in
{{core/common/src/types/options/mod.rs}}; 0 is the server default, u64::MAX
never expire). So:
* {{messageExpiry=3600}} (one hour) creates a topic whose messages expire after
3.6 ms;
* {{messageExpiry=604800}} (one week) gives 0.6 s.
There is no error and no log: the server removes the expired data at its next
clean-up, also data that a consumer has not read yet. Users who set the option
get the opposite of what they asked for.
Trigger: {{messageExpiry}} > 0 with {{autoCreateTopic=true}} (default), on the
producer or the consumer endpoint that creates the topic.
h3. Reproduction
New test {{IggyTopicMessageExpiryTest}} (4 tests, mocked Iggy client, no
server) captures the expiry passed to {{createTopic}}. Three fail on main:
* {{messageExpiry=3600}}: expected 3600000000, main 3600;
* {{messageExpiry=1}}: expected 1000000, main 1;
* {{messageExpiry=9223372036854775807}}: expected u64::MAX (never expire), main
9223372036854775807 (about 2.5 hours in microseconds).
{{messageExpiry=0}} stays 0 (passes on main, kept as a guard).
A Z3 model of the chain (seconds, BigInteger, server u64 micros with the 0 and
u64::MAX sentinels) finds the counterexample for every positive value on main
and shows that the fix gives the documented expiry for all values in [0,
Long.MAX_VALUE].
h3. Proposed fix
Convert the seconds to microseconds; a value above u64::MAX microseconds (about
584 000 years) becomes u64::MAX; 0 and negative values are passed as before.
With the fix the camel-iggy unit tests pass: 17 run, 0 failures, 0 errors, 0
skipped. Note for the 4.24 upgrade guide: topics created before keep their
wrong expiry and must be changed on the Iggy server.
Affected: main (tested); camel-4.23.x (Iggy client 0.9.0) has the same line;
camel-4.22.x (client 0.8.0) and camel-4.18.x (client 0.6.0) pass the value the
same way, the unit of those older clients was not checked (read, not run).
Duplicate check (2026-10-17): JIRA text "iggy" (all camel-iggy issues:
CAMEL-22222, 22234, 22779, 23149, 23532, 25289), none about the expiry. GitHub
pull requests "iggy expiry": none.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
