35390800c7
Two smaller operational items. POSTGRES 512M -> 1G. DATABASE_MAX_CONNECTIONS is 30 for a ~100-guest event (feed polling + SSE + uploads at once), and 30 backends plus Postgres 16's default shared_buffers leaves very little headroom at 512M. An OOM here doesn't degrade one feature -- every request path touches the database, so it takes the event down. Memory is the cheaper knob than shrinking the pool back and reintroducing the queueing it was raised to fix. .env.example now names the pairing explicitly, the way it already does for COMPRESSION_WORKER_CONCURRENCY. SOCIAL WRITES WERE UNTHROTTLED. toggle_like, add_comment and delete_comment were the only mutating endpoints in the app with no limit at all -- upload, join, recover, export and admin login all carry one. Asymmetric coverage rather than a deliberate decision. Low severity, and honestly so: a like fans an SSE broadcast to every client, but the export regeneration a comment deletion triggers is contained (REGEN_DEBOUNCE 20s, workers born with their epoch, superseded ones inert). So the ceiling is 120/min -- far above anything a real guest produces. This bounds a script, not an enthusiastic double-tapper. ONE bucket across all three actions: separate buckets would let a caller triple the aggregate write rate by alternating between them. Keyed per USER, matching the feed and upload limits -- at a venue every guest is behind one NAT, and an IP key is what made the /join and /feed limits turn guests away in the first place. Migration 020 seeds both keys, and both are wired into the admin allowlist, the config UI and the e2e reseed -- the step two earlier per-area toggles missed, which left switches that existed in code and could never be flipped. Tests: 4 e2e, including that the shared bucket really is shared (the part most likely to be lost in a refactor) and that one guest hitting the ceiling doesn't block another behind the same IP. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
17 lines
975 B
SQL
17 lines
975 B
SQL
-- Per-user rate limit for social writes (likes, comments, comment deletions).
|
|
--
|
|
-- These were the only writes in the app with no limit at all. Every other mutating
|
|
-- path -- upload, join, recover, export, admin login -- carries one; social.rs
|
|
-- carried none, so the coverage was asymmetric rather than deliberately open.
|
|
--
|
|
-- Severity is genuinely low for an invited-guest event, and the amplification worry
|
|
-- turned out to be contained: a like fans an SSE broadcast to ~100 clients, but the
|
|
-- export regeneration it could otherwise trigger is debounced (REGEN_DEBOUNCE 20s)
|
|
-- and superseded workers are inert. So this closes the gap for symmetry, not urgency,
|
|
-- and the ceiling is set high enough that no real guest will ever meet it -- a
|
|
-- double-tapping enthusiast at a wedding is not the thing being defended against.
|
|
INSERT INTO config (key, value) VALUES
|
|
('social_rate_per_min', '120'),
|
|
('social_rate_enabled', 'true')
|
|
ON CONFLICT (key) DO NOTHING;
|