Stale document previews: versioned cache keys and safe publication

Include the business document version or immutable source digest, output format, and rendering options that affect the result. If changing fonts or converter versions can change output, decide whether those dependencies belong in the key or trigger an explicit regeneration. A cache keyed only by filename will collide across copies and survive renames unpredictably. Scope private document results by the appropriate tenant or access boundary. Content identity and authorization are separate concerns: knowing the cache key should never grant permission to retrieve its object.

preview identity = source version + output mode + rendering options
preview metadata = document ID + source version + renderer revision
current pointer = only a preview matching the intended current version

These are design ingredients, not an instruction to concatenate untrusted strings into a path. Normalize and validate the fields, and retain ordinary access checks when serving cached objects. Include renderer or font changes in regeneration policy when they can affect the result.

Distinguish a content-addressed immutable result from an endpoint named current. The former can often be cached for a long time under the correct private-access rules. The latter represents a changing selection and needs validation or cache controls consistent with that promise. A browser refresh is not a dependable invalidation protocol.

When a user reports a mismatch, compare the document version selected by the page, the source version recorded on the preview, and the URL actually served by the browser. Those three observations localize the problem: wrong selection, late publication, or a stale downstream response. Purging every cache may conceal the defect without identifying which relationship broke.