Stop the map throwing away the ground you just looked at

[CaYatur]

Fixes the reported "harita parça parça yükleniyor, başka yeri yükleyince diğer yerin tekrar yüklenmesini bekliyoruz". #157 made the parse 9.7x faster; this is the client, which was throwing the results away.

Three faults

1. It deleted what it had. The desktop trimmed with trimTiles(tiles.current, visibleChunks()) — keep the current viewport, drop everything else. Pan one screen and the screen you came from was gone; pan back and all of it was re-fetched. That is the reported bug, exactly. The web kept an 8-chunk margin, which only moves the edge.

Replaced by tilesToDrop in @shared/livemap: nothing is dropped until the cache is over its limit, and then the tiles farthest from the view go first. What survives is a ring of recently visited ground.

2. The limit guaranteed churn. 2048 tiles against a viewport that requests up to 4096 — so a single view could exceed the cache, evict tiles it had just fetched, and re-fetch them on the next draw. Now 8192, with TILE_KEEP_LIMIT > MAX_VIEWPORT_CHUNKS asserted rather than remembered.

3. It asked in bands, and re-asked for what it was already waiting on. 64 chunks per request with one in flight is 64 sequential round trips for a full viewport. Now 512 — eight rounds. And because the viewport is walked in order, the chunks whose region was still being parsed were always at the front of the next request too, so the map spun on one band while the rest stayed blank; a chunk that comes back neither drawn nor listed empty is now left alone for 400 ms while the request moves on.

The trap this had to avoid

MAX_TILES_PER_REQUEST was a constant in worldTiles.ts plus two hardcoded 64s in the clients. Raising only the clients would have been silently destructive: the server reads its cap and the response then mentions neither the excess chunks nor a reason, and both handlers read that silence as "empty" —

else if (known.has(k) || !r.pending) tiles.current.set(k, null)   // null = read, nothing there

With a cache-hit response (pending === 0) every unexamined chunk would have been marked permanently blank. So the constant now lives once in @shared/livemap, imported by the main process and interpolated into MAP_JS, and the !pending inference is gone — empty is the servers actual answer, and every requested chunk comes back drawn, listed empty, or still pending.

Verification

All three checks were proved failable before being trusted (MSMS_SMOKE_WEB, by exit code):

break	failure
restore the viewport-only rule	the cache was not trimmed to its limit: 2500
invert the distance order (still trims to exactly the limit)	a tile in view was dropped: 0,0
desync MAP_JS back to 64	the web map asks for 64 but the server reads 512

The retention fixture holds 10000 tiles, past the 8192 limit — the function early-returns below it, so a small fixture would step over the body entirely and pass with the whole policy deleted. It asserts the reported property directly: after panning one screen right, at least 2000 of the previous screens 2500 tiles are still held. It also asserts determinism, since a redraw between two calls must not change what is kept.

Gates green: MSMS_SMOKE, MSMS_SMOKE_WORLDS, MSMS_SMOKE_MODUPDATE, MSMS_SMOKE_WEB.

Costs, stated

• Memory. 8192 baked 16x16 canvases instead of 2048. Roughly 25-30 MB of canvas objects in the worst case, against re-fetching and re-baking a screen every time you pan back.
• Draw loop. drawableChunks iterates every held key and splits it per draw, so that loop is now up to 8192 entries instead of 2048 — around a millisecond per pan event. Both would be fixed properly by baking one canvas per region instead of one per chunk (512x512 rather than 1024 small ones), which is worth doing but is a separate change to the draw path.
• What this does not address: zoomed out past 4096 chunks nothing is requested at all, by design, because a chunk is then a fraction of a pixel. The map draws what it holds, which after this change is much more than it used to be. Doing it properly needs downsampled zoom levels — a real feature, not a tuning change.

Closes #159

[Copilot]

Pull request overview

This PR fixes live map client-side tile churn by changing cache eviction from “keep only current viewport” to a size-based eviction policy that drops the farthest tiles first, while also increasing per-request chunk caps and removing a dangerous “pending === 0 implies empty” inference that could permanently blank unexamined chunks.

Changes:

• Centralizes map tuning constants in @shared/livemap (request cap, viewport cap, cache keep limit) and updates clients/server/docs to stay in sync.
• Replaces viewport-only trimming with distance-ranked eviction that only activates after exceeding the cache limit.
• Improves fetch behavior by increasing request batch size and adding a short per-chunk retry backoff while regions are still pending.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/shared/mapUi.ts	Updates web map JS generation: request caps, pending backoff, and farthest-first trimming.
src/shared/livemap.ts	Adds shared constants and the tested tilesToDrop eviction policy helper.
src/shared/apiSurface.ts	Updates endpoint docs to reflect new map/tiles request cap.
src/renderer/src/components/LiveMap.tsx	Updates desktop map client to use shared constants, tilesToDrop, and pending backoff.
src/main/smoke.ts	Adds smoke assertions for eviction determinism and client/server cap sync.
src/main/core/worldTiles.ts	Removes duplicated request-cap constant; re-exports shared constant for server parsing.
docs/openapi.json	Updates OpenAPI description to match the new request cap.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[CaYatur]

Self review

Read the diff back. One real regression, one leak — both on the branch (2607ab6).

1. The backoff could stall the map completely

This is the one that mattered. The new backoff stops the client re-asking for chunks whose region is still being parsed. But every chunk on screen usually belongs to the same handful of regions, so they all back off together and the request list comes out empty:

const want = visibleChunks().filter(/* not held, not backing off */)
if (!want.length) return          // ← scheduled nothing

The only retry is if (r.pending > 0) setTimeout(…, 180) inside the response handler — and in this state there is no response coming. So the effect returned having scheduled nothing at all. On the desktop the deps are view/vp/dim, none of which change while you sit still, so the view stops filling indefinitely; on the web it recovered on the 2-second refresh. Either way it presents as "the map loaded part of it and then stopped", which is the bug this branch exists to fix. I would have shipped it.

Both clients now schedule their own return at the soonest outstanding backoff.

Tested by driving it, not by reasoning about it. MAP_JS runs in a vm with a recording setTimeout and a host whose every response says "still reading":

• pass 1 asks, everything comes back pending
• pass 2 finds everything backing off → asserts a wake-up was scheduled, and that it did not re-ask (the behaviour the backoff is for)
• asserts something actually ended up backing off, so it cannot pass by never reaching the case
• asserts the delay is within 50-400 ms rather than merely non-zero

Removing the wake-up fails it: a fully-backed-off view scheduled no wake-up; the map would stall.

2. The backoff map outlived its tiles

trimTiles deleted from tiles and marks but not from waiting, so the desktop accumulated one entry per chunk ever looked at, for the life of the window — the exact unbounded growth the surrounding comment is about. The web copy already cleared it in mapTrimTiles; now they agree.

Checked and left alone

• Sort cost. tilesToDrop sorts every held key when over the limit — 10 000 entries, about a millisecond, and only on a fetch that is already crossing an IPC boundary. Not worth a heap for that.
• trimTiles only runs when there is something to fetch. A stationary view over fully-cached ground never trims — but it also never grows, so there is nothing to trim.
• The 400 ms backoff is a literal in both clients rather than a shared constant, unlike the three caps. It is a client-side pacing choice with no cross-surface contract to violate: if the two disagree, each is merely more or less eager. The caps are shared because disagreement there corrupts the map.

Disclosed

The desktop client is React and is not driven by the vm harness — the equivalent stall fix there is verified by inspection and by the shared logic (tilesToDrop) being tested directly. The two fetch loops are deliberately the same shape so that reading one is reading both, but that is a convention, not an assertion.

Gates green by exit code: MSMS_SMOKE, _WORLDS, _MODUPDATE, _WEB, _ANALYSIS, _AUDIT.