14 SEPTEMBER 2026 · clone1 · 392 batches
Run report
The queue as it now stands, after three corrections landed during the day. Every number is read straight out of file_migration_queue and file_migration_batches.
- References
- 787,448775,094 distinct objects
- Marked copied
- 786,70999.91%
- Missing sources
- 7390.09%
- Failed
- 0across 392 batches
FILE_MIGRATION_DRY_RUN currently defaults to true, and the ledger agrees with that: across every run, zero destinations were ever found already present — including 15 category images that two descriptors queued to the identical path. So these rows most likely record where each file would go rather than a completed transfer.
What is not in doubt is that the existence checks ran. FILE_MIGRATION_SKIP_COPY would have produced no skips at all, and the missing count moved precisely when a path was corrected — which is only possible if the bucket was being read.
What changed today3 corrections
equipment_models.files5,088 skips → 0
Every one of its sources sat under inventory-reference/files/, where no object is stored — 87% of every skip in the run. A migration repointed the column at inventory/user-manual/; after a re-seed all 5,088 copied. The destination never changed: the descriptor pins ModelSpecFile, so they were always headed for doc/model-library/spec-files/.
…equipment_details.referenceImages71 objects → 22
It is a projection of equipment_models.images, so it belongs to the model library. Being folder-derived it read inventory/images/ as AssetImage and filed one shared picture once per referencing account — seven of its 22 files under six accounts each. Now pinned to ModelImage, landing once at img/model-library/.
…equipmentCategoryData.imgalready correct
The same shape — a library record snapshotted onto a transaction line — but its folder categories/ maps to a library-scoped module, so 46 accounts collapse onto 39 objects. Re-seeding produced byte-identical rows, which is what confirms it was right rather than accidentally right.
What is still missing739
One reason throughout: Source file not exist. Nine descriptors carry it, and the two invoice keys are 81% of what is left.
At 0.09% of 787,448 references this is the ordinary residue of a decade of records — deleted files whose rows still name them. The one structural gap, equipment_models.files, is closed.
Batches392, all completed
completed392 of 392
792,686 files across all passes, including the re-seeded rows. No batch left partial or failed.
throughput521 files/sec
2,030 files per batch on average, 30.6 seconds each; the first full pass took 25 minutes.
records repointed0
Write-back has not run, and is refused while the dry-run flag is on. Every source column still names its legacy path.
owner slot resolved0 left as {SCOPE}
Every destination carries a real account, a library branch, or no owner by design.
Coverage91 of 122
inventory_sticker_details.sticker_name holds 745,064 of the 787,448 references — everything else combined is 42,384. Pacing, batch size and lane count are effectively tuned for that one descriptor.
31 descriptors seeded nothing. That is not necessarily wrong — a column holding no legacy paths on this clone correctly produces no rows — but it does mean a quarter of the descriptor table is still unproven against real data. The descriptor list marks which ones, and shows a real stored value for each of the 91 that did seed.