AntFleet

Disagreement · a2392d54-anthropic-4

Misleading comment: 'SSR uses initialNow' but server component re-computes a fresh `new Date()` on every render

solo Opus
repo e24ef98c·PR #7·reviewed 2 weeks ago

Opus finding

Misleading comment: 'SSR uses initialNow' but server component re-computes a fresh `new Date()` on every render

lowdocs-gaphigh
  • apps/web/app/activity/ActivityView.tsx:53-60
  • apps/web/app/activity/page.tsx:30-32
The comment claims server and client 'agree on initialNow, preventing hydration mismatch'. But page.tsx is `export const dynamic = 'force-dynamic'` and computes `new Date().toISOString()` on every server render. There is no shared snapshot between the SSR HTML rendered for the initial network response and any subsequent re-render; the claim is technically correct only because the SSR HTML is what hydrates (the client uses the exact ISO string from the server payload). The comment is correct but easy to misread; more importantly, since `formatRelativeTime(now, new Date(lastSweepAt))` runs during SSR with the server's now, and again during the hydration pass with `new Date(initialNowIso)`, they will agree on the first hydration tick — but any string formatting that depends on sub-second precision could still mismatch. Low severity, primarily a clarity issue.

Recommendation

Tighten the comment to: 'Server renders with `initialNowIso` baked into the HTML; hydration parses the same ISO string so the first client paint matches. Then useEffect switches to client clock and starts the per-second tick.'

Other reviewer

The other reviewer flagged nothing in this file/line range.

Why this didn't post

This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.

read the methodology →