Stale-write checkpoint requires a server-time RPC — revisit

[jtnelson]

Claim being questioned

Runway's stale-write detection (save(preventStaleWrites=true)) uses a checkpointTs on each Record — a server-assigned timestamp captured at load and re-stamped after every successful save. The check compares the record's audit() history against checkpointTs: any revision newer than the checkpoint means the in-memory state is stale.

The current design requires:

• A server-time RPC on every load (today ridden on the read batch via Reader#time(), so essentially free for batched paths).
• A server-time RPC on every save (separate round trip after commit() returns).

The claim is that the checkpoint must be a server-assigned timestamp because it gets compared against the server's audit() revision timestamps and client clocks skew. The conclusion was that the RPC is unavoidable short of a Concourse API change.

Why it's annoying

A no-validation save that should be one round trip becomes two purely to capture the post-commit checkpoint. Goes against the spirit of the batching work.

Things to explore

• Per-record monotonic version number returned with reads, compared on save (no clocks at all).
• Content hash / checksum of loaded state, compared on save instead of timestamps.
• Restructure save so Concourse's in-transaction conflict detection covers the load-to-save window.
• Client-side synced-clock estimate against server skew/drift.
• Server-time piggybacked on every response — client always has a fresh server-time reference without an explicit RPC.

None is obviously better than today; each has its own design problem. Filing to keep the question open.

Related

• Checkpoint Records with a server time recorded on the batch #121 — the implementation work that surfaces the cost.
• Drop long checkpoint parameter from Runway.instantiate* / instantiateAll* #122 — internal threading cleanup, independent of the underlying claim.