Kuadrant / Kuadrant/kuadrant-operator
responseBodyJSON in when predicates is not a coherent concept for TokenRateLimitPolicy limits: should be validated and rejected
- 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
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