Freegle / Iznik / 25298 / 25298

73%

master: 73%

push

circleci

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

12183 of 14025 branches covered (86.87%)

Branch coverage included in aggregate %.

75869 of 111113 relevant lines covered (68.28%)

34.34 hits per line