Kuadrant / Kuadrant/kuadrant-operator

responseBodyJSON in when predicates is not a coherent concept for TokenRateLimitPolicy limits: should be validated and rejected

Open
#2,145 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
94
Forks
89
Avg merge
3d 4h
Merged PRs (30d)
43

Description

### Summary
`TokenRateLimitPolicy` limits accept `responseBodyJSON(...)` in `when` predicates today, but this is not a coherent thing to express: a limit's `when` predicates apply to both the pre-flight check and the post-response report for that limit. The check runs *before* the upstream call is made — a response, and therefore a response body, cannot exist yet. There is no reading of `responseBodyJSON` in a `when` predicate that is meaningful for this policy type; it should never be accepted, not merely "used more carefully."

### Evidence
Tested live against a TokenRateLimitPolicy with:
```yaml
when:
- predicate: request.path == "/v1/chat/completions"
- predicate: responseBodyJSON("/object") != "error"
```
Every request logs:
```
wasm log kuadrant-wasm-shim: Missing json property: /object
wasm log kuadrant-wasm-shim: Task failed: "1"
wasm log kuadrant-wasm-shim: Task failed: "2"
```
and Limitador's `authorized_calls`/`report_calls`/`limited_calls` never move — the limit is never enforced, silently. `TokenRateLimitPolicy.status` reports `Enforced: True` throughout, with nothing indicating the limit isn't active.

Even when the referenced JSON pointer happens to resolve (e.g. `responseBodyJSON("/model")`), no runtime error occurs, but the check call can only have executed *after* the response existed — i.e. after the upstream LLM call it should have gated had already completed. It degenerates into a redundant post-hoc counter bump, not a pre-flight gate. There's no working interpretation here, just different failure shapes depending on the response.

### Expected behavior
`responseBodyJSON` should be rejected outright when it appears in a `TokenRateLimitPolicy` limit's `when` predicates, at policy validation/admission time, with the policy's `Enforced` condition set to `False` and a clear message explaining why. Silent acceptance followed by silent no-op/failure at the data-plane level is the specific behavior to eliminate.

Contributor guide

Open the contributing guide

Research direction

Start at the TokenRateLimitPolicy validation or admission entry point and trace how when predicates are parsed and validated. Add coverage for responseBodyJSON in a limit predicate, then verify admission rejects the policy, sets Enforced to False, and reports a clear explanation.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
backend-api-design, devops
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.