MigrationCheckpointStore
interface MigrationCheckpointStore
Where a migration remembers how far it got.
A copy of ten million points will be interrupted at least once, and starting over is not an answer. After every batch that Qdrant has acknowledged, the migration writes the id it reached here; on the next run it reads that id and resumes from it.
The default is inMemory, which survives nothing and is right for a test. Anything that has to survive the process needs a durable one: FileMigrationCheckpointStore on the JVM, or your own — a row in whatever database the job already writes to is usually the least new machinery.
Implementations are called from one coroutine at a time and need no locking of their own.