fix: normalize client and server map bounds #34
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/m3-bounds-normalization"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes M3 from bugs.md.
With
worldCopyJump: truethe Leaflet center wraps but the bounds edges don't, so a viewport at the antimeridian arrived aswest: 170, east: 190and zoom 1–2 aswest < -180;validate_boundsrejected both and the client froze on stale bounds — no spatial update, no historical load.map_helpers.ts): wrap each edge into[-180, 180)(double-modulo keeps JS remainder signs out); a span ≥ 360° sendswest: -180, east: 180bounds_updater.ex): longitudes now wrap modulo 360 instead of being rejected; spans ≥ 360° collapse to the whole world, which the area cap (64,800 = full globe) already permitsVerification: focused map_live suite 378 passed, full suite 2235 passed, credo strict clean,
mix esbuild map_jsbuilds.🤖 Skippy PR review
1 finding — none blocking.
test/aprsme_web/live/map_live/bounds_updater_test.exs:194Reviewed
cbdb77aa9ac2. Commentskippy reviewto re-run.@ -175,3 +192,3 @@{:noreply, result} =BoundsUpdater.handle_bounds_update(%{north: 34.0, south: 32.0, east: 1.0e9, west: -97.0}, socket)BoundsUpdater.handle_bounds_update(%{north: 34.0, south: 40.0, east: -90.0, west: -97.0}, socket)🔵 Suggestion — Rewritten pending-bounds test passes for the wrong reason
%{north: 34.0, south: 40.0, ...}is rejected byvalidate_bounds/1(canonical?/1requiressouth <= north), sohandle_bounds_update/2returns before it ever reaches thehistorical_loadingbranch — delete that branch and this test still passes, so the guard its name describes is now uncovered.Give it valid bounds (e.g.
%{north: 35.0, south: 33.0, east: -94.0, west: -98.0}) and it fails, because the branch assignspending_bounds: map_bounds: the newest bounds win, which is whatHistoricalLoader+{:process_pending_bounds}expect. Assert that instead:The deleted
rejects south > northcase is now only covered incidentally by this test's short-circuit.c71d1bc8931fab14e91a🤖 Skippy PR review
2 findings — 1 blocking before merge.
test/aprsme_web/live/map_live/bounds_updater_test.exs:196__omp_magic/2is undefinedtest/aprsme_web/live/map_live/bounds_updater_test.exs:204historical_loadingbranchResolved 1 earlier finding fixed in
c71d1bc(the pending-bounds test now uses valid bounds, so it actually reaches that branch); 0 left open. Reviewed c71d1bc..head only.Reviewed
c71d1bc8930c. Commentskippy reviewto re-run.@ -173,2 +194,3 @@test "does not overwrite pending bounds while historical loading is in flight" dotest "newest bounds win while historical loading is in flight" dosocket = build_socket(%{map_bounds: @bounds, historical_loading: true, pending_bounds: @bounds})new_bounds = %{north: 35.0, south: 33.0, east: -94.0, west: -98.0}🟠 High — Test file cannot compile:
__omp_magic/2is undefinedThe literal source at this line is
__omp_magic("", "{north: 35.0, south: 33.0, east: -94.0, west: -98.0}")(checked against the raw blob atc71d1bc, not just the rendered diff), and__omp_magicis defined nowhere: nodef, no import, no alias, no dep. Compiled Elixir resolves that call and fails, so this file does not build andmix test/precommitcannot run at all — the "full suite 2235 passed" verification in the description is not reproducible from this commit. It also looks like a mangled literal: the map lost its%sigil and ended up as a string. Fix and re-run:@ -180,0 +201,4 @@# {:process_pending_bounds} reload picks up the newest bounds when it# finishes.assert result.assigns.pending_bounds == new_boundsassert result.assigns.map_bounds == @bounds🔵 Suggestion — Rewritten test still does not pin the
historical_loadingbranchThe invalid-payload half of my earlier comment is fixed, but this test would still pass with the
historical_loadingclause inhandle_bounds_update/2deleted: the fallbackschedule_bounds_update/2also assignspending_bounds: map_bounds(bounds_updater.ex:139) and leavesmap_boundsuntouched, so both assertions hold either way. The only observable difference is the debounce timer —nilon this path, aProcess.send_afterref on the fallback, which also callsHistoricalLoader.cancel_pending_loads/1and kills the in-flight batches this branch exists to protect. Pin it with one line:Resolved 1 earlier finding — the pending-bounds test now uses valid bounds and asserts newest-wins (
bounds_updater_test.exs:194), so the branch it was meant to cover is exercised again.Force-push note:
c71d1bc8was rewritten (it carried a mangled__omp_magic(...)literal), so the incremental diff was unavailable and I re-read the whole PR diff. The delta since the last reviewed head is that one test line — nothing new.Also closing 4716 (high — test file does not compile): at
1fab14e9that line readsnew_bounds = %{north: 35.0, south: 33.0, east: -94.0, west: -98.0}and__omp_magicappears nowhere in the tree —c71d1bc8..1fab14e9is exactly that one line, so the file builds again. That commit also answers the earlier pending-bounds finding (valid bounds, newest-wins assertion), so it is resolved too.4717 stays open (suggestion, not blocking): the test still passes if the
historical_loadingclause is deleted, since the debounce fallback also assignspending_boundsand leavesmap_boundsalone.assert result.assigns.bounds_update_timer == nilpins the branch.Resolved 1 of 1 earlier finding.
d8652baaddsassert result.assigns.bounds_update_timer == nil(bounds_updater_test.exs:207), which is exactly the pin that was missing:build_socket/1defaults the key tonil, thehistorical_loadingclause never assigns it, and the debounce fallback would assign aProcess.send_afterref, so deleting that branch now fails the test. 0 still open.Nothing new in
1fab14e9..d8652ba(test-only assertion: a comment plus the assert).