Confirmed the completed PESO and LEOPARD production ingestion remains fully validated: 3,037 scoped resources, exact expected distributions, complete parent/reference trees, and create-only reruns with zero updates.
Ran a fresh local vxData deployment and indexed both datasets. Configured a separate local vxData API to presign against the deployed Ceph endpoint without persisting credentials.
Reproduced the dashboard viewer in headless Chrome against patient PE00001, including real base TIFF and HistoMap objects.
Proved that the deployed object gateway supports signed ranged GET requests: 206, exact byte counts, Content-Range, and Accept-Ranges. Signed query strings survive direct fetches and the Vite proxy. A GET-presigned URL returns 403 for HEAD, but GeoTIFF.js does not use HEAD.
Corrected the earlier CORS conclusion. Ceph permits known production origins and the Range request header, but exposes only ETag. A browser fetch from the real https://dashboard.fra.virdx.dev origin received 206 and bytes but could not read Content-Range or Accept-Ranges. GeoTIFF.js reads Content-Range, so production CORS must expose it.
Found and bypassed a stale local ui-components/dist build that initially lacked loadImageFromSource.
Wired S3 histology sources through the existing development proxy and made its URL absolute so TileClient does not incorrectly prefix it with /api/histo.
Fixed deterministic overlay cancellation in TileViewer: visible overlay keys now participate in cancelExcept, and cancelled overlay loading state is cleared in the overlay cache.
Browser validation after the fix showed valid 206 requests for base and map ranges, no cancelled map requests, a visible PESO map, and deeper zoom requests for both base and map TIFFs.
Committed the product fix on fk/fix/histo-s3-viewer as a1c0bc75. Relevant format, lint, typecheck, test, build, and module-boundary checks passed.
Lessons Learned: Pitfalls
A failed localhost CORS probe does not prove production origins are blocked. Probe each allowed origin or execute fetch from the real browser origin.
Access-Control-Allow-Headers: range allows the request, but GeoTIFF.js also needs Content-Range in Access-Control-Expose-Headers. A successful 206 alone is insufficient.
Workspace packages are consumed from dist; after checking out fresh main, rebuild ui-components and restart Vite with forced dependency optimization before trusting browser results.
Root-relative GeoTIFF URLs are interpreted relative to the tile API base by TileClient, not the page origin.
Lessons Learned: Improvements
Update the histology serving SOP with the exact production object CORS contract: allow GET and request header Range, and expose at least Content-Range plus ETag (optionally Accept-Ranges).
Add a browser-level check from the deployed dashboard origin that asserts a ranged GET returns 206 and JavaScript can read Content-Range.
Document the workspace dist rebuild requirement for local dashboard development.
Add a focused scheduler regression check ensuring visible overlay keys survive frame cancellation and cancelled overlay cache entries become requestable again.
