Date snapshot banners from the snapshot and check captureSnapshot's poll URL #79
Description
Three small faults on the share path remain after #77.
Snapshot banner date. A snapshot share's banner dates the snapshot from the share's createdAt, while the slot reads cite when each slot first served the frame it shows. A live share switched to a snapshot days after it was created shows the creation date.
Unchecked poll URL. captureSnapshot in src/lib/search/snapshot.ts joins the poll URL the API returns to its base without checking it, unlike the proxy routes, which build every upstream path through forwardablePath. This predates #77.
Corpus copy. src/content/dfo-docs/corpus/hub/build/share.md quotes the old snapshot dialog copy. The corpus is synced from upstream, so the fix belongs there.
Done when
- A snapshot banner shows the time the snapshot was taken.
-
captureSnapshotrefuses a poll URL thatforwardablePathwould refuse. - The synced corpus quotes the current snapshot dialog.
Metadata
Metadata
Assignees
Labels
No labels
Activity
jm-rivera commentedon Nov 5, 2026
The snapshot banner needs no code change. A search snapshot is stored seconds after its mint, so its
createdAtis the right "data as of", and the mint manifest'sprepared_atwould print an older date. A canvas or card share switched to a snapshot dates each card from its share history'sfirst_served_at, and nothing a reader sees readscreatedAtafter the switch.One gap remains. A Studio share made directly as a snapshot shows its card's saved frame, which can be older than the share, and no field in the share answers dates a frame. DevelopmentFinanceObservatory/apis#268 asks dfo-apis to return the frame's
prepared_at.#124 makes
captureSnapshotpoll only the path built from a checked operation id. DevelopmentFinanceObservatory/docs#21 fixes the quoted dialog copy, and a re-sync layer on top of the stack will close this issue once that PR publishes.fix(search): poll a snapshot's operation only at the path built from …