concurrency/state

Two Clocks In One Decision

#72rare4 sightingsfirst seen September 2026

What goes wrong

An expiry or countdown compares a timestamp issued by one clock (the server, another node) against the current time of a different clock (the browser, the serving machine) instead of using a duration measured on the issuing clock, so clock skew or a clock-sync jump expires it too early, extends it, or lets it back in.

Example

The server issues an expiry time; the browser compares it with its own clock, and a user whose laptop clock is five minutes fast sees 'session expired' right after logging in.

Not to be confused with

The two clocks disagree; not a time-limited ownership that runs out before the work it protects can stop (Lease Before Work Deadline), not a timezone mix-up and not an inclusive versus exclusive interval error.

Discovered by

@sks24git GitHub

Field notes · 1

@sks24git2026-09-08
A close-the-window UPDATE checked that the row's window was open, not that it was the row the selection rule picks. With two open rows it closed the shadowed fallback and returned 200 naming a "next" that never stopped.
Put the selection rule inside the mutation. A guard that re-derives "active" its own way is wrong for the table.
Seed the production shape in tests. Two open rows caught what one row cannot.