Handle stdin EOF gracefully in MCP stdio mode (#3428)

[anushakolan]

Why make this change?

When dab start --mcp-stdio was launched by a client (such as MCP Inspector or VS Code) and the client closed the stdin pipe (EOF), the process crashed with exit code 4294967295 instead of exiting cleanly. This caused noisy error signals in any tool or host that expected a clean 0 exit on shutdown.

What is this change?

Modified McpStdioServer.RunAsync to handle stdin EOF as a normal shutdown signal:

• Replaced direct Console.OpenStandardInput() + StreamReader with Console.In (testable, injectable)
• Added explicit null check on the return value of ReadLineAsync — null means EOF, which now triggers a clean return instead of an unhandled exception
• Blank lines continue to be skipped as before

How was this tested?

Unit Tests

Added McpStdioServerRunAsyncTests:

• RunAsync_EofOnStdin_ExitsGracefullyWithoutOutput — feeds empty stdin, verifies clean exit with no stdout output
• RunAsync_BlankLineThenShutdown_IgnoresBlankLineAndHandlesShutdown — feeds blank line + shutdown request, verifies single valid response and clean exit

Manual Testing

• Reproduced the exact reported scenario: piped an initialize request then closed stdin — verified EXIT_CODE=0

  echo '{"jsonrpc":"2.0","method":"initialize",...,"id":1}' | dab start --config dab-config.json --mcp-stdio
  echo "Exit code: $?"   # was 4294967295, now 0
  

• Verified EXIT_CODE=0 for normal shutdown request path
• Verified successful MCP tool calls (read_records, describe_entities) continue to work after the change

[Copilot]

Pull request overview

This PR improves the robustness of DAB’s MCP stdio hosting path by treating stdin EOF (client closes the pipe) as a normal shutdown signal rather than an error condition that terminates the process with a noisy non-zero exit code.

Changes:

• Updated McpStdioServer.RunAsync to read from Console.In and to exit cleanly when ReadLineAsync returns null (EOF).
• Added unit tests validating clean exit on EOF and correct handling of blank lines followed by a shutdown request.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Service.Tests/UnitTests/McpStdioServerRunAsyncTests.cs	Adds unit coverage for EOF-on-stdin and blank-line handling in the MCP stdio loop.
src/Azure.DataApiBuilder.Mcp/Core/McpStdioServer.cs	Treats stdin EOF as graceful shutdown by returning from the read loop when ReadLineAsync yields null.

[aaronburtle]

nit: leaks test concerns into production code. from a production standpoint, the rationale here I think is that we want to honor the configured Console.In ie:

// Read via Console.In so the loop honors the configured Console.InputEncoding
// (set to UTF-8 by Program.Main for stdio mode) and shares the SyncTextReader.

[aaronburtle]

nit: Console.SetIn is process-global, if we ever parallelize this test it could break other tests that read Console.In. Can instead extract the read source, and then tests can pass a StringReader directly.

[aaronburtle]

nit: parsing this line as JSON and then asserting on jsonrpc/id/result.ok would align more closely with the other mcp tests while being a bit more robust.

[aaronburtle]

Looks good, just a couple nits.

[Aniruddh25]

Do we no longer need utf8NoBom for stdin? Why was it needed before and what changed?

[Aniruddh25]

Approving with some questions to avoid regression around UTFNoBOM