Apache Camel ftp: with idempotent repository, repository value not removed

I have a Spring Boot 2.5 application using Apache Camel 3 ftp component.

The route reads from the ftp server and writes the file to the local file system.

Multiple application instances will be running so file locking is required. I am using a Redis idempotent repository (RedisIdempotentRepository).

I am testing the robustness of the lock with 400 files.

The route is below with the key arguments.

from("ftp://" + ftpHost +
                "/" + ftpRootDirectory +
                "&localWorkDirectory=" + declarationRootDirectory +
                "&delay=5s" +
                "&readLock=idempotent" +
                "&recursive=true&binary=true&delete=true" +
                "&idempotent=true&shuffle=true" +
                "&readLockRemoveOnCommit=true" +
                "&idempotentRepository=#ftdFtpIdempotentRepository"
.to("file://" + declarationRootDirectory);

With the over the document name is added to the storehouse yet it isn't erased once the record has been handled. The accompanying boundary doesn't appear to work. 'readLockRemoveOnCommit=true'

Assuming the key isn't eliminated then one more document with a similar name on the FTP server won't be handled. I would truly prefer not to surrender it to an expulsion strategy. I expect the FTP part ought to eliminate the passage from the storehouse.

Would somebody be able to demonstrate why the repo section isn't being eliminated?

Taking a gander at the source code it appears to be just an InProgressRepository will eliminate the repo section. This isn't expressed in the Camel documentation.

I have attempted it and it works. Be that as it may, after a couple of testing emphasises the course, in the end, neglects to deal with the records. I don't know whether this is a bug however neglecting to handle the records isn't OK.

Utilizing a mix of both 'idempotentRepository' and 'inProgressRepository' additionally works. I notice that the FTP part will endeavour to add the repo section two times. However, generally speaking, it does what I want and it appears to be strong.

------------------------------

code from ftp vs tcp.