Freegle / Iznik / 25298

73%

Build Type

push

circleci

Committed by invalid-email-address

Commit Message

fix(browse): ship reach bounding-box, not the full polygon — 64MB→45KB, fixes "no posts"

The nearby/mygroups feed selected ST_AsText(rr.polygon) as reach_wkt for every
in-reach post. The reach-gate's exact display polygons are huge (measured up to
~1.25MB of WKT each), so a single browse load serialized tens of MB - one heavy
user's feed was 64,326,257 bytes across 264 rows - and the query ran 30-52s
(apiv2 SLOW SQL log on prod). Clients timed out and showed NO posts
(discourse 9870, howiestarling@gmail.com et al). The backfill makes it worse
over time: every post it processes gains a full exact polygon.

reach_wkt is consumed only by ReachRadiusMetres (the relevance score's 'close'
term), which takes the farthest polygon vertex from the origin. The polygon's
bounding-box envelope gives that extent for ~100 bytes instead of megabytes, so
select ST_AsText(ST_Envelope(rr.polygon)) in all three arms (reach, own-posts,
mygroups). Same-user feed payload drops 64MB -> 45KB (264 rows), max row
1.25MB -> 197B, and the query returns fast.

Visibility is unchanged: the WHERE still tests ST_Contains on the FULL polygon,
so which posts appear is identical - only the score's 'close' denominator now
uses the bounding radius (a small, uniform over-estimate that just nudges
ordering). Mod reach-map endpoints that draw the real polygon are untouched.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ka6SXbZyznGYXyCyC9C86h

Coverage Stats

12754 of 16824 branches covered (75.81%)

Branch coverage included in aggregate %.

3 of 3 new or added lines in 1 file covered. (100.0%)

2 existing lines in 2 files now uncovered.

133487 of 184867 relevant lines covered (72.21%)

38.04 hits per line