Throttle /activities and /api/v1/activities per IP

[Br3nda]

Why

/api/v1/activities is the single busiest route in production, and the only high-volume one with no rate limit at all.

From a 14 minute window of growstuff-prod router logs:

Route	Requests	% of all
/api/v1/activities	216	19.6%
/crops/:id	164	14.9%
(assets)	110	10.0%
/plantings	91	8.3%
/plantings/:id	63	5.7%

The throttle matched plantings|harvests|members only, so activities — web and API — was unprotected on a dyno that is currently being OOM-killed every ~9 minutes.

What changed

Added activities to the req/ip/restricted_routes throttle, and collapsed the two alternations into a single regex with an optional /api/v1 prefix so the HTML and API route lists can't drift apart:

restricted_routes = %r{^(/api/v1)?/(activities|plantings|harvests|members)(/|$)}

Please read this before assuming it fixes the load

It does not stop the client currently hammering that endpoint, and I don't want that to be a surprise.

Those 216 requests are only 10 distinct URLs, and 189 of them come from a single IP walking page[offset] 10→80 for one owner on a loop. But it makes those 189 requests over 21 minutes — about 9 requests per minute, comfortably under the 15/min limit. On top of that, Rack::Attack counters live in a per-worker MemoryStore (deliberately, per #4800), so at WEB_CONCURRENCY=2 each worker only ever sees about 4.5/min of it.

So this PR closes the hole; it doesn't reduce today's traffic. Actually throttling that client needs one or more of:

• WEB_CONCURRENCY=1, which unifies the counters (and is the fix for the OOM crashes anyway)
• a lower limit on this rule, which would also affect plantings/harvests/members and wants its own discussion
• caching the endpoint — 10 distinct URLs re-requested every ~40s is close to ideal cache material

Happy to follow up with whichever of those you prefer.

Testing

• Verified the new regex is exactly equivalent to the old pair plus the five activities cases, across both route families. /plantingsfoo, /memberships, /activitiesfoo, /foo/plantings and /api/v2/activities remain unmatched, so there are no new false positives.
• rubocop config/initializers/rack_attack.rb — 3 offences, byte-identical to the 3 already on dev (lines 54, 61, 64, none of them mine). No new offences.
• rspec spec/requests/rack_attack_spec.rb — 2 failures, both pre-existing; confirmed identical on a clean tree with this branch stashed.

No spec added, deliberately: this throttle is registered inside if Rails.env.production?, evaluated once at boot, so it isn't reachable from the test environment without restructuring the initializer. That's also why the existing spec file covers the blocklists but no throttle. Worth fixing separately if we want throttle coverage.

Those two pre-existing failures are the honeypot and excessive-crawling ban tests — i.e. the ban machinery itself. Worth a look on its own, because those bans are held in per-worker memory and production currently restarts every ~9 minutes, so long-window bans never accumulate there either.

🤖 Generated with Claude Code

[CloCkWeRX]

Weird, we shouldn't even have that many activities!

[CloCkWeRX]

TODO: Check https://github.com/Growstuff/homeassistant-growstuff/blob/dev/custom_components/growstuff/sensor.py#L68 or add a user agent so its a bunch easier to see if this is part of the problem