davsclaus opened a new pull request, #25726: URL: https://github.com/apache/camel/pull/25726
## Summary Fixes a mailing-list-reported regression where `readLockRemoveOnCommit=false` (and `readLockRemoveOnRollback=false`) is silently ignored: a previously committed idempotent-repository entry gets removed the next time a file with the same idempotent key is polled, even though it should be retained. Two independent places in camel-file assumed "file did not start processing" implies "we must have added this idempotent entry ourselves, so it's safe to remove" — which is false whenever the entry pre-existed (e.g. from an earlier, already-committed run, or another node in a cluster): 1. `FileIdempotentRepositoryReadLockStrategy` / `FileIdempotentChangedRepositoryReadLockStrategy` / `FileIdempotentRenameRepositoryReadLockStrategy`: `releaseExclusiveReadLockOnAbort()` unconditionally called `idempotentRepository.remove(key)`. This method only ever runs after `acquireExclusiveReadLock()` failed — either because the key already existed (not ours to touch), or because a secondary check (changed/rename) failed after we added it, in which case `acquireExclusiveReadLock()` already cleaned up its own key. So the extra remove was always either wrong or redundant. 2. `GenericFileConsumer`'s "not started" cleanup (added by CAMEL-21947 / commit 71090b4b0b6) removed from `endpoint.getIdempotentRepository()` whenever `isIdempotentEager()` (defaults to `true`) and a repository is configured — without checking `isIdempotent()`. For `readLock=idempotent-changed`/`-rename` setups the repository is populated by the read-lock strategy, not by the polling-time eager dedup path CAMEL-21947 intended to guard, so this reached into entries it never added. ## Test plan - [x] Added `FileIdempotentChangedReadLockRemoveOnCommitTest`, which reproduces the exact reported scenario: process a file with `readLock=idempotent-changed` and `readLockRemoveOnCommit=false`, then re-drop a file with the same idempotent key and assert the original entry is retained (previously failed — the duplicate got reprocessed and/or the entry was wiped). - [x] `mvn test` in `components/camel-file` — all pass. - [x] `mvn test -Dtest="org.apache.camel.component.file.**"` in `core/camel-core` — 431 tests, 0 failures. - [x] `camel-ftp` compiles against the changed API; its `FtpReadLockNotStartedIT` (CAMEL-21947 regression test) explicitly sets `idempotent=true`, so it is unaffected by the added `isIdempotent()` guard. _Claude Opus 4.8 on behalf of davsclaus_ -- 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]
