1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
//! A stand-in parent process for the child-reaping tests. Not product code.
//!
//! The interesting failure this crate guards against is what happens to an MCP
//! server when the process that started it dies *without running any code*: a
//! `SIGKILL`, or on the terminal a signal it never handled. A test cannot prove
//! that about itself, because proving it means killing the process doing the
//! asserting. So the test kills this instead.
//!
//! What it does is deliberately thin, and all of it goes through the real
//! product path: build a [`Command`] for the MCP fixture server, hand it to
//! [`McpServer::connect`], and then hold the connection open forever. There is
//! no lifecycle handling here at all, which is the point. Everything that
//! happens to the child when this process is killed is what
//! `salvor_tools::mcp` arranged at spawn time, not something this file
//! contributed.
//!
//! Usage, from a test:
//!
//! ```text
//! salvor-mcp-parent <path-to-salvor-mcp-fixture>
//! ```
//!
//! Environment variables prefixed `SALVOR_MCP_FIXTURE_` are forwarded to the
//! server, so the test names the pid files and asks for the stubborn mode the
//! same way it does when it spawns the fixture directly. This process prints
//! `ready` on a line of its own once the session is live, so a test can wait
//! for the connection rather than for a duration.
//!
//! [`Command`]: tokio::process::Command
//! [`McpServer::connect`]: salvor_tools::mcp::McpServer
use Write;
use ;
async