[
https://issues.apache.org/jira/browse/CAMEL-25725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-25725.
---------------------------------
Resolution: Fixed
> 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
> Priority: Major
> Fix For: 4.24.0
>
>
> 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)
