oscerd opened a new pull request, #26427:
URL: https://github.com/apache/camel/pull/26427
The sixth finding of the `components/camel-infinispan` audit that produced
CAMEL-24622/24623/24624 — it was
in the report but slipped out of that batch.
### The problem
An expiry needs both an amount and the unit it is expressed in, and the
producer requires both headers:
```java
protected boolean hasLifespan(Message message) {
return !InfinispanUtil.isHeaderEmpty(message,
InfinispanConstants.LIFESPAN_TIME)
&& !InfinispanUtil.isHeaderEmpty(message,
InfinispanConstants.LIFESPAN_TIME_UNIT);
}
```
When only one of the pair is set the condition is false and the write falls
through to the plain
`cache.put(key, value)` overload — so a route that sets
`CamelInfinispanLifespanTime` and forgets
`CamelInfinispanTimeUnit` stores an entry that **never expires**, with
nothing in the log to say the expiry
was dropped. Same for `CamelInfinispanMaxIdleTime` /
`CamelInfinispanMaxIdleTimeUnit`. Eight operations are
affected — PUT, PUTASYNC, PUTALL, PUTALLASYNC, PUTIFABSENT,
PUTIFABSENTASYNC, REPLACE, REPLACEASYNC — and
there is no endpoint option to fall back on, since neither value has one:
the headers are the only way to
express expiry. For a cache used as a TTL store this surfaces much later, as
growth that nobody can explain.
### The change
The two checks now share one helper that warns when exactly one half of a
pair is present:
```
WARN InfinispanProducer - Both CamelInfinispanLifespanTime and
CamelInfinispanTimeUnit are needed to set an
expiry on cache misc, but only CamelInfinispanLifespanTime is set on the
message, so the entry is stored
without one.
```
Nothing else changes: the entry is still stored, and a message with neither
header (the overwhelmingly
common case) logs nothing.
**On failing instead of warning.** For CAMEL-24623 I kept the lenient
behaviour because a test had asserted
it since CAMEL-9624 (2016). There is no such contract here —
`hasLifespan`/`hasMaxIdleTime` were extracted
in CAMEL-9740 (2016) from older inline conditions, and every test in
`InfinispanProducerTestSupport` sets
both headers together, so nothing pins the current behaviour. I still went
with a warning rather than
throwing, because a route that half-sets the headers works today and would
start failing at runtime on
upgrade, which is a poor trade for a misconfiguration that is now visible in
the log. Happy to make it throw
instead, with an upgrade-guide entry, if you prefer.
### Tests
`InfinispanEmbeddedProducerExpiryTest` (new, 4 tests) covers the decision
table for both pairs: neither
header, both, amount-only, unit-only. The two protected checks are reached
through a small subclass, which
is also how the production code uses them.
Verified that the warning really fires, rather than trusting a green test: a
full run of the embedded suite
(94 tests) produces **exactly four** warnings in
`target/camel-infinispan-test.log` — the four half-set
cases from this test — and none from the neither-header or both-headers
cases. No pre-existing test in
either module trips it, so nothing in the codebase was relying on the silent
drop.
`mvn install -DskipITs` green on both modules (94 embedded, 13 remote). Full
reactor
`mvn clean install -DskipTests -DskipITs -Dquickly` green.
---
_Claude Code on behalf of oscerd_
🤖 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]
