Repository navigation
fix(proxy): route on pathname so query strings match - #86
Conversation
request.url includes the query string, so exact matches like /v1/models missed any request with query parameters and returned 404. Codex appends ?client_version=<version> when refreshing its model catalog, so every refresh failed. Match /health, /ready, /v1/models, /v1/responses, and /v1/messages on the path with the query stripped. Strip at the first '?' rather than parsing with new URL(): it cannot throw on a malformed target and does not reinterpret '//host/...' targets, so absolute-form and other unknown targets still 404 as before. Fixes #84
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 51 minutes. View limit details
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Query-free route matching and validation packages/proxy/src/server.ts, packages/proxy/test/server.test.ts, .changeset/proxy-route-query-strings.md |
The proxy uses the query-free path for draining checks and route matching. Integration tests cover queried health, readiness, model, Responses, Messages, and unknown routes. The changeset records the patch. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix · Severity of issue fixed: Medium
Possibly related PRs
- robertn702/reasoning-router#85: This PR addresses the same query-string route matching defect and adds coverage for the affected routes.
Merge Risk: 
Minimal · up to 28493
-
Queried routes can now match without changing upstream requests. No merge-blocking issue was identified.
Pre-merge checks: 
4 · 
1
-
Failed checks: 1 warning Passed checks: 4 passed-
Full details: Linked Issues check
-
Explanation
Issue
#84requires query-bearing requests to match the route path.requestPathremoves the query fromrequest.url, andserver.tsuses it for health, readiness, model, Responses, Messages, draining, in-flight, and provider checks. The added test covers all five routes with queries and verifies that/v1/unknown?client_version=1keeps the existing 404 response. The implementation also keeps upstream model forwarding at/models, as required by the current behavior.
Full details: Out of Scope Changes check
-
Explanation
The changes are limited to proxy route matching, focused query-string coverage, and a patch changeset for
@reasoning-router/proxy. The test changes directly verify issue#84and preserve unknown-route behavior. No unrelated implementation or test changes are shown in the supplied summary and file evidence.
-
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 2 files. (1 skipped: 1 unsupported.)
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches: 💡 1
-
📝 Generate docstrings: 💡
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
/v1/messages only routes when an Anthropic upstream is configured. The query-string fix touches that predicate, so assert the 404 still holds for /v1/messages?beta=true on an app built without an Anthropic upstream.
What this fixes
GET /v1/models?client_version=1returned 404 because the proxy matched routes againstrequest.url, which includes the query string (#84). Codex appends?client_version=<version>when refreshing its model catalog, so the refresh failed on every session./health,/ready,/v1/responses, and/v1/messageshad the same exact-match problem.What changed
packages/proxy/src/server.tsrequestPath(request): returnsrequest.urlwith everything from the first?removed.createAppServerrequest handler: the draining check (/health,/ready) and the in-flightproxiedcheck userequestPath.handle: every route match (/health,/ready,/v1/models,/v1/responses,/v1/messages) and the provider selection userequestPath. Method checks and the 404 body for unknown paths are unchanged.?overnew URL(request.url, "http://localhost").pathname: it can't throw on a malformed request target and doesn't reinterpret//host/...targets, so absolute-form targets (covered by the existing Host validation test) still return 404.packages/proxy/test/server.test.ts: new "query strings" test. With a query string appended, each route still reaches its handler (/health,/ready,/v1/models,/v1/responses,/v1/messages), and/v1/unknown?client_version=1still returns404 {"error":"not_found","message":"unknown route"}. Before the fix this test fails withexpected 404 to be 200..changeset/proxy-route-query-strings.md: patch bump for@reasoning-router/proxy.The query string still isn't forwarded upstream;
/v1/modelskeeps calling<upstream>/models, which is how it already behaved for bare requests.Verification
npm run checkpassed with exit 0: typecheck passed, Biome reported no errors, and Vitest ran 36 files with 477 tests passing. The one Biome warning is already onmain, inpackages/classifiers/test/jev.test.ts.Built the proxy (
npm run build) and ran it on port 4392 against a stub upstream on 4391 (REASONING_ROUTER_UPSTREAM_AUTH=forward).Before, with
server.tsfrommain:After:
Fixes #84
Summary by CodeRabbit