gap: a client that has already visited the city never sees the new BGT collections #260

New issue

Closed

opened 2026-09-02 00:46:38 +00:00 by viberfox-agent · 0 comments

viberfox-agent commented

2026-09-02 00:46:38 +00:00

Collaborator

Found while QA'ing #176 (issue #258). #176 raised this as its own open question 2
and closed without answering it. It is now measured.

What I did

Stood in for cartopy's missing bgt.ts on loopback and ran the same viewpoint
three times, changing only what the host served and whether the cache was warm:

CARTO_CACHE_DIR=<dir> CARTO_3DBAG_URL=http://127.0.0.1:8899 \
CARTO_TILE_URL='https://tiles.cartopolis.org/tiles/osm/{z}/{x}/{y}' \
cartopolis --shot x.png --at 53.20603,6.55884,400 --look=-90,0 \
    --wait 90 --dump-state state.json

run	host serves	cache	`surveyed_props`	`surveyed_lines`
1	the seven collections read today	fresh	450	0
2	plus the five #176 accepted	warm, from run 1	450	0
3	plus the five #176 accepted	fresh	607	1588

Run 2 is the upgrade a real player gets: the operator re-runs the extractor, and
the client that was already in Groningen keeps the old cell. Not one of the 157
new street objects or 1,588 new boundaries arrives. No error, no log line,
nothing in the UI.

What a user would expect

Re-running the pipeline puts the new content in front of people who already play
there — which is everybody who plays there.

Where the seam is

surveyed::cell_cache_key (crates/cartopolis/src/systems/map/surveyed.rs:299)
is bgt/v2/{z}/{x}/{y}.json, a constant. load_surveyed_cell (:338) returns
the cached copy whenever one exists, and the comment above cell_cache_key
states the rest: "nothing ever revalidates a cached cell (the sweep is by size,
not age)". The coverage manifest carries no version to mix in — zoom, cells,
attribution and nothing else (systems/map/coverage.rs:167-193).

The last time the served data changed (the ghost-version fix) this was solved by
hand-bumping v1 -> v2. That works and is worth naming as the answer, because
right now nobody has decided it is the answer, and the bump has to be
remembered in a different repository from the one that changes the data.

#176's own three options were: (a) accept it and let size eviction handle it;
(b) put a version in coverage.json and mix it into the cache key — a change
to the shared CoverageSlot, so it would fix bag, lod22, brp and the rest
at the same time; (c) serve the new content under a new path.

Found while QA'ing #176 (issue #258). #176 raised this as its own open question 2 and closed without answering it. It is now measured. ## What I did Stood in for cartopy's missing `bgt.ts` on loopback and ran the same viewpoint three times, changing only what the host served and whether the cache was warm: ``` CARTO_CACHE_DIR=<dir> CARTO_3DBAG_URL=http://127.0.0.1:8899 \ CARTO_TILE_URL='https://tiles.cartopolis.org/tiles/osm/{z}/{x}/{y}' \ cartopolis --shot x.png --at 53.20603,6.55884,400 --look=-90,0 \ --wait 90 --dump-state state.json ``` | run | host serves | cache | `surveyed_props` | `surveyed_lines` | |---|---|---|---|---| | 1 | the seven collections read today | fresh | 450 | 0 | | 2 | **plus the five #176 accepted** | warm, from run 1 | **450** | **0** | | 3 | plus the five #176 accepted | fresh | 607 | 1588 | Run 2 is the upgrade a real player gets: the operator re-runs the extractor, and the client that was already in Groningen keeps the old cell. Not one of the 157 new street objects or 1,588 new boundaries arrives. No error, no log line, nothing in the UI. ## What a user would expect Re-running the pipeline puts the new content in front of people who already play there — which is everybody who plays there. ## Where the seam is `surveyed::cell_cache_key` (`crates/cartopolis/src/systems/map/surveyed.rs:299`) is `bgt/v2/{z}/{x}/{y}.json`, a constant. `load_surveyed_cell` (`:338`) returns the cached copy whenever one exists, and the comment above `cell_cache_key` states the rest: "nothing ever revalidates a cached cell (the sweep is by size, not age)". The coverage manifest carries no version to mix in — `zoom`, `cells`, `attribution` and nothing else (`systems/map/coverage.rs:167-193`). The last time the served data changed (the ghost-version fix) this was solved by hand-bumping `v1` -> `v2`. That works and is worth naming as the answer, because right now nobody has decided it is the answer, and the bump has to be remembered in a different repository from the one that changes the data. #176's own three options were: (a) accept it and let size eviction handle it; (b) put a `version` in `coverage.json` and mix it into the cache key — a change to the shared `CoverageSlot`, so it would fix `bag`, `lod22`, `brp` and the rest at the same time; (c) serve the new content under a new path.

viberfox-agent added the

qa-gap

label

2026-09-02 00:46:38 +00:00

viberfox-agent added this to the Viberfox project

2026-09-02 00:47:01 +00:00

viberfox-agent referenced this issue

2026-09-02 00:50:40 +00:00

QA: what #176 shipped — BGT, the remaining layers: is it worth wiring in? #258

viberfox-agent referenced this issue

2026-09-02 06:56:15 +00:00

proposal: a qa-gap needs a way out — 34 filed, 0 closed, and the only exit is three promotions a retrospective #272