allthingssecurity opened a new pull request, #28033:
URL: https://github.com/apache/camel/pull/28033

   # Description
   
   [CAMEL-25725](https://issues.apache.org/jira/browse/CAMEL-25725)
   
   The `messageExpiry` option is documented as "Message expiry time in 
seconds". `IggyEndpoint.initializeTopic` passes it unchanged to 
`TopicsClient.createTopic`; the Iggy client sends it as the u64 option 
`message_expiry`, and the Iggy server reads that value in microseconds 
(`IggyExpiry::from(u64)` -> `Duration::from_micros`, with 0 = server default 
and u64::MAX = never expire). A topic created by Camel (`autoCreateTopic=true`, 
the default) therefore expires its messages a million times too early: 
`messageExpiry=3600` gives 3.6 ms instead of one hour, and the server removes 
data that consumers have not read.
   
   Change: `toIggyExpiry` converts the seconds to microseconds. A value above 
u64::MAX microseconds (about 584 000 years) becomes u64::MAX, which Iggy reads 
as never expire. 0 and negative values are passed as before.
   
   What users can notice: topics created by Camel get the expiry the option 
documents. Topics created before keep their expiry and must be changed on the 
Iggy server; a note is added to the 4.24 upgrade guide.
   
   Tests:
   - New `IggyTopicMessageExpiryTest` (4 tests) captures the expiry passed to 
`createTopic` on a mocked Iggy client (no server).
   - Without the change: 3 of the 4 fail (`expected: <3600000000> but was: 
<3600>`, `expected: <1000000> but was: <1>`, `expected: <18446744073709551615> 
but was: <9223372036854775807>`). `messageExpiry=0` passes on main too and is 
kept as a guard that 0 stays 0.
   - With the change the camel-iggy unit tests pass: 17 run, 0 failures, 0 
errors, 0 skipped.
   
   What is not changed: `maxTopicSize` (bytes on both sides), the stream 
creation, existing topics.
   
   What was not run: the integration tests against an Iggy container, and the 
full root build.
   
   # Target
   
   - [x] I checked that the commit is targeting the correct branch (Camel 4 
uses the `main` branch)
   
   # Tracking
   - [x] If this is a large change, bug fix, or code improvement, I checked 
there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for 
the change (usually before you start working on it): 
[CAMEL-25725](https://issues.apache.org/jira/browse/CAMEL-25725).
   
   # Apache Camel coding standards and style
   
   - [x] I checked that each commit in the pull request has a meaningful 
subject line and body.
   - [ ] I have run `mvn clean install -DskipTests` locally from root folder 
and I have committed all auto-generated changes.
     (I built and tested camel-iggy, including the formatter and import-sort 
plugins. I did not run the full root build.)
   
   # AI-assisted contributions
   
   - [x] If this PR includes AI-generated code, commits have proper 
co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR 
description identifies the AI tool used.
     This PR was prepared with Claude Code (Claude Opus 5.5). The commit 
carries a `Co-Authored-By` trailer.
   
   _Claude Code on behalf of allthingssecurity_
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to