Carry a file's timestamps into its prerendered rendering - #5986
Conversation
The FileDef shells render "· 4y ago" from `meta.lastModified`, but the resource the fileRender pass hydrates its FileDef from is the extract's, and that resource never carried timestamps. A live file-meta read stamps them from the index row, so a file's prerendered HTML omitted the modified time that the same file's live render showed. Any surface that can show either — the search sheet falls back to a live item while a row's HTML is still pending — read differently depending on whether the HTML was there yet. Thread the row's `lastModified` / `resourceCreatedAt` through the render options into the extract, the route the content hash and size already take, and stamp them onto the resource through `fileMetaTimestamps` like every other file-meta producer. Both visits forward them: the fused index visit and the standalone prerender-html visit. An extract that fetched the file itself (the store's in-render fallback, a room attachment) reads them off the response's `last-modified` / `x-created` headers instead. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Preview deploymentsHost Test Results 1 files ± 0 1 suites ±0 2h 28m 2s ⏱️ - 8m 51s Results for commit c5a50c2. ± Comparison against earlier commit 5656129. Realm Server Test Results 1 files ±0 190 suites ±0 1h 6m 52s ⏱️ - 1m 24s Results for commit c5a50c2. ± Comparison against earlier commit 5656129. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Empty commit. The modified segment this branch adds is rendered with Intl.RelativeTimeFormat against the clock at snapshot time, so a build of identical code is the test for whether those labels are stable: a clean run means the timestamps behind them are fixed, and any diff means a snapshot's metadata moves on its own and would keep doing so after merge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
lukemelia
left a comment
lukemelia
left a comment
There was a problem hiding this comment.
[Claude Code 🤖] Reviewed the timestamp-parity mechanism end to end: the epoch-seconds form threaded through RenderRouteOptions, the serialize/parse roundtrip (both keys gated behind fileExtract), the four file-meta producers now agreeing on the resourceCreatedAt key mapping via fileMetaTimestamps, and both the fused index-visit and standalone-prerender paths into buildFileResource. Did not re-run Percy.
No blocking issues. The fused index path and a live file-meta read now stamp the same meta.lastModified / resourceCreatedAt, and the header fallback covers the interactive extract (the store's extractFileMetaDirectly).
- One non-blocking follow-up: the standalone prerender-html visit lacks the index visit's
unixTime(Date.now())floor for a nullfileRef.lastModified, so in that narrow case the baked HTML can still omit a modified time the row would show — see the inline note onvisitForPrerenderedHtml.
The standalone prerender visit left `fileLastModified` off its render options when the adapter reported no mtime, while the index visit floors that case to `unixTime(Date.now())` and writes the floor to the row. Since this visit runs after that one, the row already held a modified time the baked HTML did not — the disagreement between the two channels this path exists to remove, reached by the one input that had no floor. The extract's `last-modified` header fallback cannot cover it here: forwarding the content hash and size is what lets the extract skip its own fetch, so no response header is read. Reaching for the row instead would be the exact fix, and is not available cheaply — `realm_file_meta` carries createdAt, contentHash and contentSize but not lastModified, and the only batch accessor for modified times is realm-wide. The two floors are therefore separate `Date.now()` reads rather than one value, which both shells render at day granularity. Narrow: it needs an adapter that reports no mtime together with a recorded content hash and size. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 participants
This is meant to address this recently-common Percy diff:
This will still have some variability but CS-12770 is for overriding
nowin the tests to prevent that.Claude: The FileDef shells render "· 4y ago" from
meta.lastModified, but the resource the fileRender pass hydrates its FileDef from is the extract's, and that resource never carried timestamps. A live file-meta read stamps them from the index row, so a file's prerendered HTML omitted the modified time that the same file's live render showed. Any surface that can show either — the search sheet falls back to a live item while a row's HTML is still pending — read differently depending on whether the HTML was there yet.Thread the row's
lastModified/resourceCreatedAtthrough the render options into the extract, the route the content hash and size already take, and stamp them onto the resource throughfileMetaTimestampslike every other file-meta producer. Both visits forward them: the fused index visit and the standalone prerender-html visit. An extract that fetched the file itself (the store's in-render fallback, a room attachment) reads them off the response'slast-modified/x-createdheaders instead.