Summary
McpServer.cs:140, 145 hardcodes recognition of notifications/initialized and notifications/cancelled only. Any other method name starting with notifications/ is silently swallowed (no response, no log) — including likely client typos (notifications/cancellation, notifications/initalized) or future spec additions. Per JSON-RPC §3 the server MUST NOT reply to notifications, but it should at least log unknown notification methods so client integration bugs surface.
Note: #186 reports the inverse-shaped bug (server replies to unknown notifications with -32601 + id:null). If #186 has since been fixed, the swallow path may now be the active behaviour — verify before fixing.
Where
Suggested approach
(1) Build a whitelist of known notification methods (notifications/initialized, notifications/cancelled, future: notifications/progress, notifications/message). Any other notifications/* method should be logged at WARN level with the method name so client typos surface in the MCP server log. (2) Don't reply (preserve §3 compliance) but record the invocation. (3) Add a --strict-notifications flag for debugging that promotes unknown notifications to a server-side error log entry surfaced via the suggestion store (cross-link C504). (4) Add regression tests: known notifications dispatch correctly, unknown notifications produce a log entry but no response, malformed notifications get logged. (5) Cross-link with #186, #1780, #1684, and the just-filed C511/C512 (other MCP transport issues).
Summary
McpServer.cs:140, 145hardcodes recognition ofnotifications/initializedandnotifications/cancelledonly. Any other method name starting withnotifications/is silently swallowed (no response, no log) — including likely client typos (notifications/cancellation,notifications/initalized) or future spec additions. Per JSON-RPC §3 the server MUST NOT reply to notifications, but it should at least log unknown notification methods so client integration bugs surface.Note: #186 reports the inverse-shaped bug (server replies to unknown notifications with
-32601 + id:null). If #186 has since been fixed, the swallow path may now be the active behaviour — verify before fixing.Where
src/CodeIndex/Mcp/McpServer.cs:140, 145(hardcoded notification name checks)-32601 Method not found+id:null— JSON-RPC 2.0 §3 violation ("Server MUST NOT reply to a Notification") #186 (server replies to unknown notifications — JSON-RPC §3 violation if still active), MCP server never emits notifications/initialized; handshake is asymmetric #1780 (server never emitsnotifications/initialized), Long-running index / backfill_fold tools emit no notifications/progress events #1684 (no progress notifications)Suggested approach
(1) Build a whitelist of known notification methods (
notifications/initialized,notifications/cancelled, future:notifications/progress,notifications/message). Any othernotifications/*method should be logged at WARN level with the method name so client typos surface in the MCP server log. (2) Don't reply (preserve §3 compliance) but record the invocation. (3) Add a--strict-notificationsflag for debugging that promotes unknown notifications to a server-side error log entry surfaced via the suggestion store (cross-link C504). (4) Add regression tests: known notifications dispatch correctly, unknown notifications produce a log entry but no response, malformed notifications get logged. (5) Cross-link with #186, #1780, #1684, and the just-filed C511/C512 (other MCP transport issues).