🐛 Bugfix: Why did the previous agent's fix for the VITTO 400 error fai...

Date: 2026-02-06
Time: 21:03:18 UTC
Session: editor2-97.10
Agent: backend
Confidence: 100%
Status: ✅ Documented

📋 Decision Context

Question:

Why did the previous agent's fix for the VITTO 400 error fail despite implementing OnApplicationBootstrap + HttpAdapterHost?

Task: Previous agent's failed WebSocket fix attempt

🎯 Decision Made

Chosen:

The fix was architecturally sound but addressed the wrong layer (app-level vs infrastructure-level)

Options Considered:

1. The OnApplicationBootstrap approach was fundamentally wrong
2. The fix was architecturally sound but addressed the wrong layer (app-level vs infrastructure-level)
3. The code had syntax errors
4. Socket.IO configuration was missing

💭 Reasoning

The previous agent correctly identified that NativeWsGateway needed noServer+prependListener for upgrade routing, and that destroyUpgrade:false was needed on Socket.IO gateways. These were valid improvements. However, the agent assumed the 400 error came from engine.io destroying the socket, when the actual 400 came from the Node.js inspector. The clue was: the error persisted even after correct WS routing was in place. The 400 response said 'WebSockets request was expected' — this is the Node.js debugger's error message, NOT engine.io's. The agent also introduced: (1) non-null assertions (this.wss!) violating eslint rules, (2) removed origin verification checks (security regression), (3) modified unrelated package.json --only flags. The lesson: when a WebSocket error persists after correct application-level fixes, look at what ELSE is listening on the port (debugger, proxy, load balancer).

📁 Files Involved

• apis/backend-ai-api/src/app/mcp-gateway/native-ws.gateway.ts
• apis/backend-ai-api/src/main.ts
• tools/scripts/dev-serve.js
• package.json

🔗 Related

• Decision ID: dev_1770411798516_jgpf5l8
• Session: 97
• Workspace: editor2

Auto-generated by MCP Smart Consolidation