• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

stacklok / toolhive / 30339578062
70%

Build:
DEFAULT BRANCH: main
Ran 28 Jul 2026 07:52AM UTC
Jobs 1
Files 845
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

28 Jul 2026 07:44AM UTC coverage: 69.717% (+0.008%) from 69.709%
30339578062

push

github

web-flow
Use standard JSON-RPC error codes and scrub leaked error text (#6066)

* Map HTTP statuses to standard JSON-RPC error codes

Three error paths passed the HTTP status straight through as the
JSON-RPC error.code: the authz response filter emitted a literal 500,
and both webhook middlewares emitted whatever status they were called
with (413, 422, or 500). Those values are legal, since they sit outside
the reserved -32768..-32000 range, but they are not the codes the draft
MCP spec designates for general protocol failures, so a client that
branches on error.code cannot recognize 500 as internal-error or 422 as
a denial.

The HTTP status and the JSON-RPC code are independent dimensions. Add
mcp.JSONRPCCodeForStatus as the single place the mapping lives: 413
becomes -32600 (an oversized body is a malformed request), 500 becomes
-32603, and 422 becomes JSONRPCCodeDenied, because the mutating path
relays a webhook's 422 always-deny response downstream while the
validating path relays the identical condition as 403 -- emitting 422
as the code would make one denial look unlike every other denial.

403 is unchanged. It is the one case where status and code legitimately
coincide, deliberately outside the reserved range so it never collides
with an SDK-generated code.

Deriving the code inside sendErrorResponse leaves all 13 call sites
untouched. The encode-failure fallback bodies are fixed too; they
spliced the raw status into the code field, so leaving them would
reintroduce the bug they stand in for.

No HTTP status changes, so audit outcomes -- which key off the status,
not the code -- are unaffected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Scrub internal error text on authorization denials

pkg/authz forwarded internal error text verbatim to callers on three
paths: the Cedar authorizer's evaluation error, a default-deny message
disclosing that a method is "not configured for authorization", and the
response filter's error, which can originat... (continued)

23 of 30 new or added lines in 5 files covered. (76.67%)

6 existing lines in 3 files now uncovered.

81086 of 116307 relevant lines covered (69.72%)

98.43 hits per line

Uncovered Changes

Lines Coverage ∆ File
4
81.29
-0.33% pkg/authz/response_filter.go
1
87.5
0.07% pkg/authz/middleware.go
1
85.45
0.2% pkg/webhook/mutating/middleware.go
1
87.6
2.0% pkg/webhook/validating/middleware.go

Coverage Regressions

Lines Coverage ∆ File
3
96.63
-0.44% pkg/authz/authorizers/cedar/core.go
2
96.05
0.0% pkg/authserver/storage/memory.go
1
81.29
-0.33% pkg/authz/response_filter.go
Jobs
ID Job ID Ran Files Coverage
1 30339578062.1 28 Jul 2026 07:52AM UTC 845
69.72
GitHub Action Run
Source Files on build 30339578062
  • Tree
  • List 845
  • Changed 10
  • Source Changed 5
  • Coverage Changed 10
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #30339578062
  • 4a61bd1a on github
  • Prev Build on main (#30337625765)
  • Next Build on main (#30341972589)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc