# Deferred Message System in DesktopCommanderMCP: Ensuring Reliable MCP Initialization Logging > Discover DesktopCommanderMCPs deferred message system in server.ts. This buffer ensures no startup diagnostics are lost during critical MCP initialization logging, guaranteeing reliable logging. - Repository: [Eduard Ruzga/DesktopCommanderMCP](https://github.com/wonderwhy-er/DesktopCommanderMCP) - Tags: internals - Published: 2026-08-06 --- **The deferred message system in DesktopCommanderMCP acts as a temporary buffer that captures log entries generated before the MCP transport is initialized, ensuring no startup diagnostics are lost during the critical initialization phase.** During the early phases of Model Context Protocol (MCP) server startup in DesktopCommanderMCP, the transport layer that delivers logs to the client does not yet exist. The deferred message system solves this timing issue by temporarily storing log messages in [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts) until the `FilteredStdioServerTransport` is fully established, guaranteeing that all initialization diagnostics reach the client. ## The Problem: Logging Before the Transport Exists When [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts) begins execution, the `FilteredStdioServerTransport` bridge responsible for forwarding logs to the client has not been instantiated. Any direct `logger.info` calls at this stage would be silently dropped, leaving developers blind to early startup failures. This creates a critical gap in observability during the MCP initialization sequence. ## Core Components of the Deferred Message System The implementation spans two primary files and consists of three key elements working together to preserve log integrity. ### The deferredMessages Buffer Located at line 83 in [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts) and line 18 in [`src/index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/index.ts), the `deferredMessages` array holds log entries as `{ level, message }` objects. This buffer acts as a temporary queue that decouples log generation from log transmission, ensuring messages persist even when the transport is unavailable. ### The deferLog Helper Function The `deferLog(level, message)` function pushes new entries onto the `deferredMessages` array. Every early-stage log call—such as "Loading server.ts"—routes through this helper to ensure capture before the transport layer is available. This function is defined in both [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts) and [`src/index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/index.ts) to handle logging at different initialization stages. ### The flushDeferredMessages Handler Exported from [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts) at line 88, `flushDeferredMessages()` empties the buffer by sending each stored message to the logger. This function serves as the bridge between the deferred buffer and active logging, called once the transport is ready to ensure the backlog reaches the client. ## Initialization Flow: From Deferral to Delivery The deferred message system operates in two distinct phases to maintain orderly startup diagnostics and enforce separation of concerns. First, during the **push phase** in [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts), the server emits informational messages by calling `deferLog`. The server module remains agnostic to transport implementation details, focusing solely on recording events without knowing how or when they will be delivered. Second, during the **drain phase** in [`src/index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/index.ts) at line 124, after creating the `FilteredStdioServerTransport` and connecting the server via `server.connect(transport)`, the bootstrap code calls `flushDeferredMessages()`. Additionally, [`index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/index.ts) iterates over its own `deferredMessages` array, sending entries via `transport.sendLog` to complete the delivery pipeline. ## Code Implementation The following examples demonstrate how to use the deferred system within the DesktopCommanderMCP codebase. To buffer logs during early initialization in [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts): ```typescript import { logger } from './utils/logger.js'; import { deferLog } from './server.js'; deferLog('info', 'Loading server.ts'); logger.info('This will also be deferred automatically'); ``` To flush the buffer after establishing the transport in [`src/index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/index.ts): ```typescript import { server, flushDeferredMessages } from './server.js'; import { FilteredStdioServerTransport } from './custom-stdio.js'; async function runServer() { const transport = new FilteredStdioServerTransport(); await server.connect(transport); flushDeferredMessages(); while (deferredMessages.length > 0) { const msg = deferredMessages.shift()!; transport.sendLog(msg.level, msg.message); } transport.sendLog('info', 'MCP fully initialized, all startup messages sent'); } ``` ## Summary - The deferred message system prevents log loss during MCP initialization by buffering messages before the transport layer exists. - [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts) maintains the `deferredMessages` array at line 83 and exports `flushDeferredMessages()` at line 88, while [`src/index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/index.ts) manages the actual transport creation and final delivery at line 124. - The `deferLog()` function captures early logs without requiring the server module to know about transport implementation details. - Once the `FilteredStdioServerTransport` is connected, the system flushes all deferred messages to ensure complete diagnostic visibility. ## Frequently Asked Questions ### What happens to logs if they aren't deferred during MCP initialization? Without the deferred message system, any log calls made before the `FilteredStdioServerTransport` is created would be silently discarded. This would make debugging startup failures extremely difficult, as critical initialization errors and "Loading server.ts" messages would never reach the client. ### Where is the deferred message buffer stored in DesktopCommanderMCP? The `deferredMessages` array is defined in [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts) at line 83 and also exists in [`src/index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/index.ts) at line 18. Both locations work together to ensure no messages are lost during the handoff between server initialization and transport connection. ### How does the deferred message system maintain separation of concerns? The server code in [`src/server.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/server.ts) only needs to call `deferLog()` without knowing about transport implementation details. The bootstrap code in [`src/index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/index.ts) handles the `FilteredStdioServerTransport` creation and calls `flushDeferredMessages()`, keeping transport logic separate from server logic and making the server module easier to unit test. ### When is the deferred message buffer flushed to the client? The buffer is flushed immediately after the `FilteredStdioServerTransport` is instantiated and the server connects to it. The `flushDeferredMessages()` function is called in [`src/index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/index.ts), which then iterates through remaining messages and sends them via `transport.sendLog` to complete the delivery to the client.