Stop splicing whole SSE buffers into error text

[jhrozek]

Summary

Two review findings against #6066 that arrived after it merged.

processEventStream splices the whole SSE buffer into its error text. When a backend's text/event-stream body contains no recognized line separator, pkg/mcp/tool_filter.go reported it as fmt.Errorf("unsupported separator: %s", string(buffer)). That buffer is the full pre-filter payload — for a tools/list, the unfiltered tool list — and the error is logged upstream, so the failure produced one unbounded log line carrying exactly the payload the filter exists to scrub. It now reports the length, which is the only diagnostic value the message ever had.

This is the byte-identical sibling of the case #6066 fixed in pkg/authz/response_filter.go. Fixing one and not the other was an oversight, not a scoping decision — the two lines differed only in the variable name.

Scoping it honestly: not client-visible and not a data leak. Both are server-log concerns, reachable only when a backend returns an SSE body with no \r\n, \n, or \r at all. The cost is log bloat and attacker-influenceable log volume, not disclosure.

A comment that contradicted its own function. handleUnauthorized's doc comment said the authorizer error "must never be promoted to a structured field routed to an aggregator beyond this log line" — while the next statement logs it as precisely such a field. The behaviour is correct and deliberate; the wording was wrong. The intent was to forbid copying it into further log lines. Reworded to say that.

Type of change

• Bug fix
• New feature
• Refactoring (no behavior change)
• Dependency update
• Documentation
• Other (describe):

Test plan

• Unit tests (task test)
• E2E tests (task test-e2e)
• Linting (task lint-fix)
• Manual testing (describe below)

go build ./... clean and go test -count=1 ./pkg/mcp/... ./pkg/authz/... green on the merged-main base.

No test needed updating: nothing in the repo asserted the old "unsupported separator" text (checked across pkg/, test/, and docs/). No new test added either — the changed line is an error-message format in a branch that requires a backend to emit a separator-free SSE body, and asserting a %d-formatted length would pin the wording without pinning the property that matters.

Linting not run locally; leaving it to CI.

Does this introduce a user-facing change?

No. Both changes are server-side only — one error message that reaches logs rather than clients, and one comment.

Special notes for reviewers

Two logical changes in one commit, which brushes the one-change-per-PR rule. They are 5 added lines total and share a single origin (post-merge review of #6066), so they are batched rather than split into two PRs of two lines each. Happy to separate them if you would rather.

The alternative was to wait. This could equally have been folded into whatever next touches pkg/mcp/tool_filter.go; the only cost of waiting is that the sibling defect stays live. Raised as its own PR because #6066 just fixed the identical line one directory over, so leaving the twin in place is the kind of thing that reads as deliberate six months later.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 72.31%. Comparing base (4a61bd1) to head (44c4c95).

Files with missing lines	Patch %	Lines
pkg/mcp/tool_filter.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6079      +/-   ##
==========================================
+ Coverage   72.26%   72.31%   +0.04%     
==========================================
  Files         725      725              
  Lines       75358    75358              
==========================================
+ Hits        54460    54495      +35     
+ Misses      17016    16965      -51     
- Partials     3882     3898      +16     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.