Function parquet_geometry_key 

pub(crate) fn parquet_geometry_key(
    cache_key: &str,
    layout: ParquetLayout,
) -> String

The flat Parquet geometry entry for a request cache key, under the LAYOUT the client asked for.

THE definition of that suffix. It used to be a format! literal repeated in parse_parquet (twice), parse_parquet_stream, try_cached_replay and here, kept equal by a comment saying they bump together – four writers and readers of one cache slot held together by prose, where a missed bump gives a reader looking up a key nobody writes, or worse a writer storing under a version an old reader still serves.

The two layouts get SEPARATE namespaces (-parquet-v8 / -parquet-v9, from ParquetLayout::cache_suffix) rather than one versioned slot, and the reason is that a version bump cannot do the job here. A cache key namespaces server-side entries; it has no bearing on which client is asking. Bumping one shared key would have retired the v5 entries and then handed every client – including one pinned to a @ifc-lite/server-client that predates #3888 – a freshly generated v6 blob it decodes without error and draws wrong. Two namespaces plus an opt-in signal means a client that did not ask for the shared layout can never be served it, from cache or from a live parse, and the two entries coexist instead of evicting each other on every request.

v8 / v9 since #5984 added the metallic / roughness finish columns: an older entry replays with no finish, where absence reads exactly like “unauthored” (the same reason #3215 took the flat layout v4 -> v5 for the source-id columns). Neither reuses v6: that was the shared layout’s namespace before #5130 moved it to v7, and such blobs may still be on disk.