Skip to content

v0.1.4 — auto-reconnect actually works after mid-session disconnects

Latest
Latest

Choose a tag to compare

View all tags
@dmang-dev dmang-dev released this 16 May 22:18
· 62 commits to main since this release
v0.1.4
39ea77d

Closes the auto-reconnect gap that v0.1.2 and v0.1.3 missed.

The bug

v0.1.2 introduced ensureConnected() so that tool calls would auto-reconnect if PPSSPP wasn't reachable. But it only worked for the initial connection. If PPSSPP was up when MCP started and then closed mid-session (taskkill, crash, user-quit), every subsequent tool call would throw:

MCP error -32603: Cannot read properties of null (reading 'send')

That's the very pre-v0.1.2 error format that v0.1.2 was supposed to make impossible.

Root cause

The WebSocket close handler cleared ws and ready to false, but left the memoized readyPromise as a resolved promise pointing at a dead socket:

ws.on("close", (code, reason) => {
  this.ready = false;
  this.ws = null;
  // ❌ this.readyPromise still points at a resolved promise for the dead socket
});

Next ensureConnected(): isConnected() returns false (ws is null), await start() returns the cached resolved promise immediately, and call() proceeds to this.ws!.send(...) → null deref.

Fix

One-line addition in the close handler: this.readyPromise = null;. Now start() actually attempts a fresh connect on the next call.

Added

  • npm run verify:reconnect (scripts/verify-reconnect.cjs) — regression test that exercises the bug specifically.
  • npm run verify:screenshot (scripts/verify-screenshot.cjs) — companion test for v0.1.3's screenshot source param.

Install: npm install -g mcp-ppsspp@0.1.4 or npx -y mcp-ppsspp

Full Changelog: https://github.com/dmang-dev/mcp-ppsspp/blob/v0.1.4/CHANGELOG.md

Assets 2
Loading