Rate limit token bucket and RSS rate-limited semantics

• Status: Accepted
• Date: 2026-02-21
• Context:
  • ERD_INDEXERS.md defines token bucket enforcement via rate_limit_try_consume_v1 and explicit rate-limited failure semantics for rss_poll_apply_v1.
  • Existing tests did not fully verify capacity-deny behavior, invalid input guards, and RSS rate-limited logging/backoff behavior from the Rust data boundary.
  • Phase 7 checklist still had rate-limit enforcement unchecked.
• Decision:
  • Add revaer-data tests to verify:
    • token bucket capacity enforcement (allowed then deny without over-consuming tokens);
    • invalid token bucket inputs return expected error details (capacity_invalid, tokens_invalid);
    • RSS rate_limited failures require rate_limit_denied_scope;
    • RSS rate_limited failures use retry path semantics (backoff scheduling) and force outbound log counters to latency_ms=0 and result_count=0.
  • Keep implementation dependency-free (no new crates).
  • Alternatives considered:
    • Rely on migration inspection only: rejected because runtime contracts can regress without executable checks.
    • Cover only via API tests: rejected because proc-level behavior is more directly and deterministically exercised in revaer-data.
• Consequences:
  • Positive outcomes:
    • Token bucket behavior and RSS rate-limited semantics are now regression-tested.
    • The checklist item for rate-limit rule enforcement can be marked complete.
  • Risks or trade-offs:
    • Time-window assertions rely on bounded jitter assumptions and may need adjustment if ERD timing constants change.
• Follow-up:
  • Implementation tasks:
    • Continue with the next unchecked ERD indexers item (Cloudflare transitions/mitigation behavior).
  • Review checkpoints:
    • just ci
    • just ui-e2e