Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: Shared MCP proxy emits an extra error for a successful client response

Open Beginner friendly
  • Is something wrong?
#6,471 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, node.js
Domain
api, backend

Research direction

Start with examples/memory-plugin-shared/lib/mcp-proxy-core.mjs, especially the handleMessage entry point and the request-versus-response handling described in the issue. Use the provided mre.mjs example with a fetch implementation returning HTTP 202 and an empty body to observe stdout. Done means a successful client response is forwarded and produces no extra JSON-RPC message, while ordinary requests, notifications, and IDs including 0 keep working.

Written by the indexing model from the issue text.

Description

Issue Origin

Observed or reproduced in a real environment

Bug Description

The memory plugins' shared MCP proxy treats a successful JSON-RPC response from the client as a request that needs another response. When the upstream accepts that response with HTTP 202 and an empty body, the proxy emits an unsolicited -32003 error on its stdout.

This happens with an ordinary successful reply to a server ping, such as {"jsonrpc":"2.0","id":"server-ping","result":{}}. No upstream failure is needed.

Steps to Reproduce
  1. Use the shared proxy source at commit 078199e37224f4376fab7411fb3029ee059b63a4.
  2. Supply the proxy with a successful fetch implementation that returns HTTP 202 with no body, then call its public handleMessage entrypoint with the response above.
  3. Capture the proxy's stdout. It contains an empty-response error even though the upstream acknowledged the client's response successfully.
Expected Behavior

Forward the client's response and write no additional JSON-RPC message to stdout after its successful acknowledgment. The MCP 2025-06-18 transport specification defines an empty HTTP 202 acknowledgment for an accepted response or notification.

Actual Behavior

{"jsonrpc":"2.0","id":"server-ping","error":{"code":-32003,"message":"OpenViking MCP upstream returned an empty response"}}

Four successful-response observations were recorded. A normal ping request with numeric ID 0 and an initialized notification behaved as expected. Successful client responses with either a string ID or numeric ID 0 both produced the extra error. All four POST inputs reached the supplied fetch implementation unchanged; its responses were one HTTP 200 and three HTTP 202 results.

Minimal Reproducible Example

Save as mre.mjs at the repository root and run node mre.mjs. This exact example was also run separately and reproduced the string-ID case; it overlaps the four-case observations and is not added to their count.

import { Writable } from 'node:stream';
import { createOpenVikingMcpProxy } from './examples/memory-plugin-shared/lib/mcp-proxy-core.mjs';

const output = [];
const proxy = createOpenVikingMcpProxy({
  stdout: new Writable({
    write(chunk, encoding, done) { output.push(chunk.toString()); done(); },
  }),
  readConfig: () => ({
    mcpUrl: 'http://ordinary.invalid/mcp', timeoutMs: 1000, watchedPaths: [],
  }),
  loggerFactory: () => ({ log() {}, logError() {} }),
  fetchImpl: async () => new Response(null, { status: 202 }),
});

await proxy.handleMessage({ jsonrpc: '2.0', id: 'server-ping', result: {} });
console.log(output.join(''));
OpenViking Version

Source at 078199e37224f4376fab7411fb3029ee059b63a4; shared proxy blob 5891599e68dfea801aca2f3e542a7b4b25601d46.

Python Version

Not applicable: Node.js 24.21.0 on x64.

Operating System

Windows

Model Backend

Other: no model or backend was called.

Additional Context

The shared core identifies requests solely by the presence of id. A JSON-RPC response also has an id, so handleMessage expects a response to it and treats the successful empty acknowledgment as missing response data.

The proposed boundary is to distinguish requests from responses when deciding whether a stdout reply is expected, while preserving normal request IDs (including 0), notifications, and message forwarding. Is this the appropriate boundary for a focused shared-proxy correction? No product patch has been made.

Validation loaded the unmodified complete shared core and its three exact-current source dependencies with Node's normal module loader. Only successful fetch responses and an in-memory output sink/configuration were supplied. No real HTTP request, deployed OpenViking server, host application, official full suite, other Node version, or model was tested. This report does not establish behavior for error responses, session recovery, or timeouts.

Dominant language
Python
Stars
40.8k
Forks
3.3k
Avg merge
1d 6h
Merged PRs (30d)
388

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from volcengine/OpenViking

All issues in volcengine/OpenViking

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.