The portal resolver compares the newest customer-visible send version against the link's own snapshot and its snapshot_refreshed_at stamp, and serves whichever is genuinely newer. Callers that don't pass the timestamp keep the older 'version always wins' behaviour.
Also called: portal showing an old estimate · customer can't see my changes · stale portal
- 1No pin → compare the freshest customer-visible send version with the link's snapshot.
- 2The comparison uses snapshot_refreshed_at — 'when the fallback was last REBUILT. Deliberately not updated_at: a customer opening the portal bumps that, and a reader must never change which document is authoritative.'
- 3With no customer-visible send version at all, the link's snapshot is used.
- 4Version history is untouched: 'every send still captures a version, and nothing here rewrites one.'
- 5On any error it returns the fallback, so the portal always renders something.
The bug is described from inside the customer's portal: 'he added $11,568 of services and two customer notes to a sent estimate and the portal showed none of it — a $37,246 quote against a $48,814 estimate. The link's snapshot had been refreshed correctly; it was losing to a `send` version captured on JULY 14 that outranked it by construction. The old rule was "latest version, else the link", which silently assumed a version is always at least as fresh as the link.'
- An old send version outranking a freshly rebuilt snapshot
- Customers quoted an out-of-date total
- A reader silently changing which document is authoritative
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →