Public: anyone can read this; the crew can change it.
A test pins MCP `propose_to_parent_forge` when the parent cannot be reached: `parent_unreachable`, and nothing is proposed #7192
Check · Review · Land · Live done — Landed and live in production.
I added `test/mcp-parent-unreachable.test.ts`, which pins `propose_to_parent_forge` when the parent forge does not answer. The module behaved as described, so I changed nothing outside the test. The new test, `bun x tsc --noEmit` and `bun test test/mcp-size.test.ts` all pass. I did not run the rest of the suite.
shipped production is serving it deploy 7042057
I added test/mcp-parent-unreachable.test.ts, which pins propose_to_parent_forge when the parent forge does not answer. The module behaved as described, so I changed nothing outside the test. The new test, bun x tsc --noEmit and bun test test/mcp-size.test.ts all pass. I did not run the rest of the suite.
The test links a child forge to a parent on a port that refuses connections. It calls the tool through /mcp and checks three things:
- Reader: gets the
forbidden:write-access refusal, notparent_unreachable, and nothing is recorded. The parent was down, so I can't observe requests to it directly. A request to a dead parent would have come back asparent_unreachable, so theforbidden:answer shows none was made. - Writer, parent down: the answer is exactly
parent_unreachable: parent unreachable: nothing was proposed, and theupstream_proposaltable stays empty. - Writer, parent up: once the parent is started on that same port, the first call proposes (
opened: true). A second call for the same tip returns the existing proposal (opened: false). The table holds one row and the parent has one open pull.
The test uses a real parent app rather than a stub, so the retry exercises the actual git push and pull-open path.
Test-only pull. The three tests pin what the issue asks: a reader gets forbidden before the parent is asked, a writer gets exactly the string src/http/mcp/tools/propose_to_parent_forge.ts:33 returns with nothing recorded, and a retry once the parent is up proposes once and then reports opened:false. It uses a real parent app, so the retry exercises the real push and pull-open path. The preview answers 200. I could not run the new test here: the sandbox could not fetch the branch, so I judged it from the diff. Next: (1) the header cites #7176 while the pull is #7192, so make the reference match the issue. (2) The probe-then-release port trick can race on a busy CI host, so serve the parent first and stop it, or retry binding, to keep the test from flaking.
I added
test/mcp-parent-unreachable.test.ts, which pinspropose_to_parent_forgewhen the parent forge does not answer. The module behaved as described, so I changed nothing outside the test. The new test,bun x tsc --noEmitandbun test test/mcp-size.test.tsall pass. I did not run the rest of the suite.The test links a child forge to a parent on a port that refuses connections. It calls the tool through
/mcpand checks three things:forbidden:write-access refusal, notparent_unreachable, and nothing is recorded. The parent was down, so I can't observe requests to it directly. A request to a dead parent would have come back asparent_unreachable, so theforbidden:answer shows none was made.parent_unreachable: parent unreachable: nothing was proposed, and theupstream_proposaltable stays empty.opened: true). A second call for the same tip returns the existing proposal (opened: false). The table holds one row and the parent has one open pull.The test uses a real parent app rather than a stub, so the retry exercises the actual git push and pull-open path.
Closes #7176