smaramwbc/statewave

Affected Component server/api/episodes.py, server/db/repositories.py (insert_episode) Bug Description Idempotent ingest dedupes the row, but the API still reports the replay as a new creation: insert_episode() (repositories.py:60-101), on an idempotency-key conflict, returns the existing episode instead of inserting. The caller can't tell that happened, so create_episode goes on to: return 201 Created, and fire the episode.created webhook again (episodes.py:61) for an episode that was created earlier. The batch route has the same problem. episodes_created=len(rows) (episodes.py:122) counts replays as created, and episodes.batch_created reports the inflated count. The idempotency key exists precisely so connectors can retry and re-run seeds safely (the docstring says re-ingest becomes "a no-op"). But every retry still sends a duplicate episode.created to webhook consumers, so cache-invalidation or audit consumers see creations that didn't happen. #282 fixed the same kind of spurious e

Affected Component server/api/episodes.py, server/schemas/requests.py Bug Description idempotency_key is validated as a request field (str | None, max_length=512, requests.py:48). For older clients, the server also falls back to reading it from metadata, but that fallback skips all validation: # server/api/episodes.py:51 (and :102 for the batch route) idempotency_key=body.idempotency_key or body.metadata.get("idempotency_key"), metadata is a free-form dict, so metadata.idempotency_key can be any JSON value, and it goes straight into a String(512) column (server/db/tables.py:40): "metadata": {"idempotency_key": 123} → asyncpg rejects an int for a text parameter → DataError "metadata": {"idempotency_key": "<600 chars>"} → StringDataRightTruncationError "metadata": {"idempotency_key": {"a": 1}} → same DataError isn't handled by register_exception_handlers (only OperationalError maps to 503), so all three come back as 500 internal_error for what is a client input problem. In the

Affected Component server/core/middleware.py — RequestIDMiddleware Bug Description The server trusts any X-Request-ID a client sends, with no length or character check: # server/core/middleware.py:19-33 request_id = request.headers.get(_HEADER) or uuid.uuid4().hex[:16] request.state.request_id = request_id structlog.contextvars.bind_contextvars(request_id=request_id) ... response.headers[_HEADER] = request_id That value then: is bound into every log line for the request (request_started, request_finished, and anything logged downstream), is echoed in the response header, and is copied into error bodies (server/core/errors.py:39 _request_id). So a client can send a multi-kilobyte request id and have it written into every log line for that request, which inflates log storage and pollutes whatever indexes request ids in the log pipeline. A request id is meant to be a short correlation token. Expected Behavior A client-supplied id is accepted only if it looks like a correlation id, e.g

Affected Component server/core/ratelimit.py — RateLimitMiddleware._check_memory Bug Description The in-memory rate limiter adds a key for every client IP it ever sees and never removes one: # server/core/ratelimit.py:30 self._hits: dict[str, list[float]] = defaultdict(list) # :66-79 timestamps = self._hits[key] self._hits[key] = [t for t in timestamps if t > window_start] # prunes the list... ... self._hits[key].append(now) # ...but the key stays forever An IP that made one request a week ago still has an entry, with an empty list after its next prune, and only if it ever comes back. Nothing iterates over idle keys. On a long-running public deployment the dict grows with the number of distinct client IPs seen since startup, with no upper bound. memory is the default strategy (server/core/config.py:142), so this is the code path every deployment with STATEWAVE_RATE_LIMIT_RPM > 0 uses unless it opts into distributed. The distributed limiter alrea

Affected Component README.md, server/core/ratelimit.py (docstring) Description The default for STATEWAVE_RATE_LIMIT_STRATEGY is documented in four places, and two of them are wrong: Where Says server/core/config.py:142 (the real default) rate_limit_strategy: str = "memory" server/core/settings_catalogue.py:396+ "memory (default, single-process)" ✅ .env.example:90 # STATEWAVE_RATE_LIMIT_STRATEGY=memory ✅ README.md:271 default distributed ❌ server/core/ratelimit.py:5 (module docstring) (default: "distributed") ❌ This matters for anyone running more than one replica. If they trust the README, they turn on STATEWAVE_RATE_LIMIT_RPM and assume the limit is shared through Postgres. In fact each process keeps its own in-memory window, so the effective limit is RPM × number of workers. Expected Behavior The README and the docstring say the default is memory, and say that multi-replica deployments need distributed. Suggested fix README.md:271: change the default colum