fix: cap the expansion hop count instead of hanging near the poles

[mailletf]

Problem

n_hops_for sizes an expansion against the smaller of a cell's height and width. Cell width shrinks with cos(latitude), so the hop count climbs steeply toward the poles:

precision	lat 60	lat 80	lat 89	lat ~90
p7	14	38	376	638,868
p9	419	1,206	11,995	1.5×10⁸

Each hop adds a ring, so a polar input built a frontier of billions of cells and never returned. If the narrowest extent ever reached zero, the division gave +inf, as usize saturated to usize::MAX, and the loop could not terminate at all.

Fix

Refuse both cases with a message naming the offending hash, the hop count and the cell's narrowest extent, so the caller can see whether to coarsen the precision or shrink expansion_m. The cap is 10,000 hops — far past any real expansion, far short of what a degenerate input produces. A 50 km expansion at precision 6 still goes through.

Splits the sizing logic into n_hops_for_core returning Result<_, String> from the thin PyResult wrapper: constructing a PyErr pulls in Python symbols the Rust test binary does not link, so the policy was otherwise unreachable from cargo test.

Also

Corrects two docstrings that said the hop count comes from a cell's height; it has used min(height, width) since the function was written.

[mailletf]

This change is part of the following stack:

• fix: don't drop multipolygon parts whose seed lands in an earlier part #30
  • perf: cover polygons by descending the geohash tree #31
    • perf: expand geohash sets on packed integers instead of strings #32
      • fix: cap the expansion hop count instead of hanging near the poles #33 ◀
        • fix: release the GIL while covering a polygon #34
          • chore: delete the dead handbrake cover #35
            • chore: cargo fmt #36
              • perf: add Arrow-native WKB and EWKB output #37
                • perf: add Arrow-native encode and coordinate decode #38
                  • perf: optionally dictionary-encode geog_id in the Arrow mapping output #39
                  • perf: cover large polygons across Rayon workers #40

_{Change managed by git-spice.}

[Copilot]

Pull request overview

Prevents geohash expansion from effectively hanging near the poles by capping the computed expansion hop count and surfacing a clear error when an expansion would require an extreme/degenerate number of rings. This fits into the library’s “geography expansion” utilities and improves safety for both Rust and Python callers.

Changes:

• Introduces MAX_EXPANSION_HOPS and adds validation in hop sizing to refuse runaway polar expansions (and other degenerate sizing inputs) with actionable errors.
• Splits hop sizing into n_hops_for_core -> Result<usize, String> plus a thin PyResult wrapper to keep the policy testable from cargo test.
• Adds Rust unit tests and Python tests covering the runaway polar case and ensuring large-but-reasonable expansions are still allowed; updates docstrings to reflect min(height, width) sizing.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/lib.rs	Adds hop-count capping + degenerate-input rejection in expansion sizing; adds Rust tests and updates expansion docstrings.
tests/test_geohash_ops.py	Adds Python regression tests for polar runaway expansions and a sanity test for large allowed expansions.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mailletf]

Leaving this one as is. The message already names the geohash and both extents (width {cell_width_m} m, height {cell_height_m} m), which is the diagnostic content — min_cell_m is just the smaller of the two, and the hop count on this branch is inf or NaN by construction, so printing it adds a number that can never be anything else. The branch exists precisely because the hop count is meaningless here.