---
title: "2026-08-26 Histo S3 viewer browser validation and overlay fix"
description: "Validated real Ceph range and CORS behavior, reproduced S3 viewer failures in Chrome, and fixed dev proxy and overlay scheduling paths."
image: "https://docs.virdx.dev/img/virdx-social-card.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.virdx.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-08-26 Histo S3 viewer browser validation and overlay fix

## Work Done

- 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.

Source: https://docs.virdx.dev/knowledge/inbox/2026-08-26-histo-s3-viewer-browser-validation-fix/index.mdx