davsclaus commented on PR #25726: URL: https://github.com/apache/camel/pull/25726#issuecomment-5423684650
Addressed the abort-after-successful-acquire correctness issue from @gnodet's first review (replies on the inline comments). Summary: - `releaseExclusiveReadLockOnAbort` in all three idempotent read-lock strategies now only removes the idempotent key when *this strategy* added it during `acquireExclusiveReadLock` (tracked via a new `Exchange.FILE_LOCK_IDEMPOTENT_ACQUIRED` property, following the same pattern `MarkerFileExclusiveReadLockStrategy` uses for `FILE_LOCK_FILE_ACQUIRED`). Pre-existing keys are left untouched; keys we acquired are still cleaned up if `begin()` fails afterwards for an unrelated reason (e.g. a `preMove` rename failure) — so this no longer reverts CAMEL-24093 for that scenario. - Added `FileIdempotentRepositoryReadLockStrategyAbortTest`, a direct unit test on the strategy covering both branches. Confirmed it fails against the previous (no-op) version of this PR. - The wording nit on the old comment is moot — the comment was rewritten as part of this fix. - Kept the test class/method `public` (not applying the minor visibility suggestion, per maintainer preference). - Noted for later: backport to `camel-4.18.x`/`camel-4.22.x` per the two reviews — will follow up with backport PR(s) after this merges. _Claude Sonnet 5 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]
