fix(fe): read batchApply as a sibling of results, not a child

onPhotosReady read results.batchApply, but on the measure capture state
batchApply is a SIBLING of results, so the read was always undefined and every
batch photo fell through to processedBlob: undefined. The Photos-ready lineup
showed all four PNGs (calibration, overlay, and both batch siblings) yet only
two images reached Woo, because publish.py selects WHERE processed_blob IS NOT
NULL. Read s.capture.batchApply.
This commit is contained in:
2026-09-25 21:10:25 -07:00
parent 350a849ab6
commit 83b58c23a3
+5 -4
View File
@@ -119,11 +119,12 @@
})
: draft();
// The session already produced the processed PNGs: the calibration
// inventory PNG in results.inventoryPng and each sibling's in
// results.batchApply (parallel to s.batch). Attach them as
// processedBlob so the server upload carries real images (PUBLISH-40).
// inventory PNG in results.inventoryPng, and each sibling's in
// batchApply (a sibling of results on the measure state, parallel to
// s.batch). Attach them as processedBlob so the server upload carries
// real images (PUBLISH-40).
const calIdx = s.calibrationIndex;
const apply = results?.batchApply;
const apply = s.capture.k === 'measure' ? s.capture.batchApply : null;
// slab_photos.id is a global primary key, so the id must be unique
// across slabs - key it on the slab id, not just the index/size.
const photos = s.batch.map((source, i) => ({