[Infra-Fix 2026-07-14] papercortex /sse 500 (Mitigation: Restart) + quorum.fichtmueller.org stale DNS bereinigt #1

New Issue

rene.fichtmueller · 2026-07-14T05:23:11Z

rene.fichtmueller commented

2026-07-14 05:23:11 +00:00

Befund

Monitoring meldete 404 an der Root von papercortex.context-x.org und quorum.fichtmueller.org.

1) papercortex.context-x.org - 500 auf /sse, jetzt behoben (Mitigation)

Root / liefert seit jeher absichtlich 404 (kein Health-Endpoint dort, dokumentiert in project-papercortex-deployment-Memory - kein Bug). Der eigentliche Live-Endpoint /sse lieferte aber unerwartet 500 statt der dokumentierten 200. Container-Logs zeigten wiederholt:

HTTP handler error: Error: Already connected to a transport. Call close() before connecting
to a new transport, or use a separate Protocol instance per connection.

Das ist ein bekanntes MCP-SDK-Pattern-Problem: der Server nutzt vermutlich eine einzelne Server-Instanz statt einer neuen Transport/Protocol-Instanz pro Verbindung (dist/mcp-server/index.js:221).

Sofortmassnahme: Container-Restart hat den haengenden Transport-State geleert - /sse liefert jetzt wieder 200, verifiziert live.

Nicht behoben (Code-Fix noetig, kein Infra-Fix): Der zugrunde liegende SDK-Bug bleibt - sobald wieder mehrere SSE-Verbindungen ueberlappend auftreten, kann derselbe Fehler zurueckkommen. Fuer eine dauerhafte Loesung muesste dist/mcp-server/index.js (bzw. die Quelle davon) pro Connection eine eigene Server/Transport-Instanz erzeugen statt eine geteilte zu wiederverwenden.

2) quorum.fichtmueller.org - stale DNS, bereinigt

quorum.fichtmueller.org war laut Projekt-Memory bereits am 2026-06-02 bewusst retired (Quorum laeuft nur noch intern hinter Argus, kein eigenes Public-URL mehr) - die zugehoerige CNAME (zeigte auf den Argus-Tunnel 80d80a1b..., aber ohne passende Ingress-Regel mehr) war jedoch nie geloescht worden und lieferte deshalb dauerhaft 404 vom Tunnel-Catch-all. Der Quorum-Prozess selbst war die ganze Zeit gesund (PM2 online, 127.0.0.1:3310 antwortet 200) - kein funktionaler Bug, nur ein verwaister DNS-Eintrag (gleiche Fehlerklasse wie der bereits behobene foghorn/steno-Fall vom 2026-07-11).

Fix: CNAME-Record fuer quorum.fichtmueller.org (Zone fichtmueller.org) via Cloudflare API geloescht. argus.fichtmueller.org hat einen eigenen, unabhaengigen Record auf denselben Tunnel und ist davon nicht betroffen (verifiziert vor dem Loeschen). DNS-Propagation kann laut frueherer Erfahrung 5-10 Min dauern.

Quelle

Teil des Infra-Sweeps vom 2026-07-14.

## Befund Monitoring meldete 404 an der Root von `papercortex.context-x.org` und `quorum.fichtmueller.org`. ## 1) papercortex.context-x.org - 500 auf /sse, jetzt behoben (Mitigation) Root `/` liefert seit jeher absichtlich 404 (kein Health-Endpoint dort, dokumentiert in `project-papercortex-deployment`-Memory - **kein Bug**). Der eigentliche Live-Endpoint `/sse` lieferte aber unerwartet **500** statt der dokumentierten 200. Container-Logs zeigten wiederholt: ``` HTTP handler error: Error: Already connected to a transport. Call close() before connecting to a new transport, or use a separate Protocol instance per connection. ``` Das ist ein bekanntes MCP-SDK-Pattern-Problem: der Server nutzt vermutlich eine einzelne `Server`-Instanz statt einer neuen Transport/Protocol-Instanz pro Verbindung (`dist/mcp-server/index.js:221`). **Sofortmassnahme:** Container-Restart hat den haengenden Transport-State geleert - `/sse` liefert jetzt wieder **200**, verifiziert live. **Nicht behoben (Code-Fix noetig, kein Infra-Fix):** Der zugrunde liegende SDK-Bug bleibt - sobald wieder mehrere SSE-Verbindungen ueberlappend auftreten, kann derselbe Fehler zurueckkommen. Fuer eine dauerhafte Loesung muesste `dist/mcp-server/index.js` (bzw. die Quelle davon) pro Connection eine eigene `Server`/`Transport`-Instanz erzeugen statt eine geteilte zu wiederverwenden. ## 2) quorum.fichtmueller.org - stale DNS, bereinigt `quorum.fichtmueller.org` war laut Projekt-Memory bereits am 2026-06-02 bewusst retired (Quorum laeuft nur noch intern hinter Argus, kein eigenes Public-URL mehr) - die zugehoerige CNAME (zeigte auf den Argus-Tunnel `80d80a1b...`, aber ohne passende Ingress-Regel mehr) war jedoch nie geloescht worden und lieferte deshalb dauerhaft 404 vom Tunnel-Catch-all. Der Quorum-Prozess selbst war die ganze Zeit gesund (PM2 online, `127.0.0.1:3310` antwortet 200) - **kein funktionaler Bug**, nur ein verwaister DNS-Eintrag (gleiche Fehlerklasse wie der bereits behobene foghorn/steno-Fall vom 2026-07-11). **Fix:** CNAME-Record fuer `quorum.fichtmueller.org` (Zone fichtmueller.org) via Cloudflare API geloescht. `argus.fichtmueller.org` hat einen eigenen, unabhaengigen Record auf denselben Tunnel und ist davon nicht betroffen (verifiziert vor dem Loeschen). DNS-Propagation kann laut frueherer Erfahrung 5-10 Min dauern. ## Quelle Teil des Infra-Sweeps vom 2026-07-14.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rene.fichtmueller/PaperCortex#1