advanced-ratelimit: invalid config accepted, GCRA panic, silent backend coercion, and malformed IETF headers

Summary

advanced-ratelimit currently accepts several invalid configurations and has runtime/behavioral gaps that can cause panics, unsafe fallback behavior, and malformed headers.

Bugs and examples

1) Zero limit accepted, then GCRA panics

• Example config:

algorithm: gcra
backend: memory
quotas:
  - name: zero-limit
    limits:
      - limit: 0
        duration: 1m

• Actual: policy creation succeeds; request processing can panic (integer divide by zero).
• Expected: reject config at validation/policy creation.

2) parseSingleLimit accepts invalid numeric domain

• Examples currently accepted:
  • limit: -1
  • duration: 0s
  • duration: -1s
  • burst: 0
  • burst: -3
• Actual: accepted and propagated.
• Expected: validation error for non-positive/invalid values.

3) Fractional limit silently truncated

• Example:

limits:
  - limit: 1.7
    duration: 1s

• Actual: accepted and cast to 1.
• Expected: reject non-integer limit values.

4) Unknown backend silently treated as memory

• Example:

backend: memroy-typo
algorithm: fixed-window
quotas:
  - name: q1
    limits:
      - limit: 10
        duration: 1m

• Actual: policy is created and behaves like memory backend.
• Expected: fail validation for unsupported backend values.

5) keyExtraction validation gaps

• Examples accepted but should fail:
  • unknown type: type: route_name_typo
  • missing required key for header/metadata/constant:
    • { type: header }
    • { type: metadata }
    • { type: constant }
• Actual: accepted, later falls back to placeholders/empty values.
• Expected: strict validation errors.

6) costExtraction validation gaps / silent fallback

• Examples accepted or silently ignored:
  • invalid shape: costExtraction: "invalid-shape"
  • unknown source type typo
  • missing required fields:
    • request_header/response_header without key
    • request_body/response_body without jsonPath
  • invalid multiplier type: multiplier: "2x"
• Actual: invalid inputs are often ignored or downgraded instead of rejected.
• Expected: strict, explicit validation errors.

7) Invalid redis.failureMode coerced instead of rejected

• Example:

backend: redis
redis:
  failureMode: half-open-typo

• Actual: value is effectively treated as closed behavior, not rejected.
• Expected: validation error for unsupported mode values.

8) Quota name not sanitized for IETF structured headers

• Example quota name: bad"name
• Actual: generated ratelimit-policy/ratelimit header contains invalid quoted structured value.
• Expected: properly escaped/sanitized structured header output.

Impact

These issues can lead to:

• runtime panic under bad config,
• silent misconfiguration and unintended backend behavior,
• non-compliant/broken response headers,
• reduced safety of configuration validation.

Requested fix direction

• Enforce strict validation for limits, backends, extraction types/required fields, and redis failure mode.
• Reject fractional limits.
• Guard GCRA against zero/invalid limits before runtime.
• Sanitize/escape quota names when building IETF structured headers.

Start at advanced-ratelimit policy creation and parseSingleLimit validation, then trace keyExtraction, costExtraction, redis.failureMode, GCRA processing, and IETF header generation. Reproduce the listed invalid configurations and malformed headers; done means invalid inputs are rejected, zero-limit requests do not panic, and generated headers are valid.