aggregator(opencode): iso() throws RangeError on out-of-range server timestamps — one bad session drops every session from that server #2286

Summary

iso() in the aggregator's OpenCode session mapper converts a server-supplied millisecond timestamp with no range/finite gate, so one session whose time.updated (or time.created) is beyond the valid Date range makes mapServerSessions throw — and every caller fails soft at the whole-server level, so that one bad session silently drops all sessions from that OpenCode server from the attention feed and the durable registry.

Evidence (main 5a34fa70)

• pm-stack/aggregator/src/sources/opencode.ts:86-87:

  const iso = (ms: number | undefined): string | null =>
    typeof ms === "number" && ms > 0 ? new Date(ms).toISOString() : null;

  typeof + > 0 admit 1e16, Number.MAX_VALUE, and Infinity-adjacent magnitudes. JS Date is only valid to ±8.64e15 ms; new Date(1e16).toISOString() throws RangeError: Invalid Date. (JSON cannot carry Infinity, but it happily carries 1e16.)
• The throw sites are unguarded: entry construction in mapOne (opencode.ts:174 createdAt: iso(s.time?.created), :179 lastActivityAt: iso(s.time?.updated)) and the long-running-call stamp at :255. mapOne/mapServerSessions have no per-session try/catch — one throw aborts the whole map.
• The bad session is reliably included before it throws: the attention filter at opencode.ts:146 is now - s.time.updated <= ATTENTION_WINDOW_MS, and for a huge future updated that difference is negative, so the session passes the filter and sorts first (:148).
• Callers fail soft only at server granularity, which is what turns one bad row into a total loss:
  • pm-stack/aggregator/src/sources/live.ts:878 (attention()) and :983 (registry()): a throw from laptopMapped() is caught and the laptop part is dropped entirely (laptopSeen = false).
  • pm-stack/aggregator/scripts/collect-fleet-feed.ts:456: the sandbox mapServerSessions call sits in a try that leaves attention = [] for the whole sandbox server on throw.

Reproduction (this run)

Sandbox Bun probe driving the real mapServerSessions against a stub v2 server (probe in /tmp/probe-laneB-ociso/probe.ts):

• Control — one normal session: entries: 1, lastActivityAt stamped correctly.
• Experiment — the same good session plus one session with time.updated = 1e16: mapServerSessions threw RangeError: Invalid Date; zero entries returned, the good session included.

Why it matters

The timestamps come from a remote OpenCode server's JSON — data this process does not control (a skewed clock, a corrupt store, a different server version). Today a single out-of-range stamp blacks out an entire server's sessions from attention + registry with no error naming the cause: the aggregator just reports the laptop/sandbox source as unreachable/fixtures. Per-session data faults should degrade per-session.

Acceptance criteria

• iso() (or its callers) returns null for any value that is not a finite, in-Date-range timestamp — no throw for 1e16, Number.MAX_VALUE, or negative/huge magnitudes.
• One session with an out-of-range time.created/time.updated/message time.created does not prevent the remaining sessions from the same server being mapped (regression test with a mixed good/bad session list against the real mapper, in pm-stack/aggregator/test/opencode.test.ts).
• Triage pins whether far-future-but-valid stamps (e.g. +1 year) also count as "fresh" in the :146 attention filter, or whether that stays as-is — record the decision on this issue.
• Existing aggregator tests pass.

Dedup

Checked open + closed issues for mapServerSessions, "opencode iso", "toISOString throws": no existing issue covers this mapper. #2196 is quota-extract's monthDayTime throw (different file/mechanism); #1540/#2253/#2264 are store/quota/snapshot date gates, distinct modules.