dead-exports:check is red on a clean main again
check-dead-exports found 1 exported symbol(s) with no reference outside their own file:
src/mcp/server.ts: MCP_SERVER_NAME (used internally — drop the `export` keyword)
test:ci runs this, so every open PR inherits the failure and none can go green. Third instance of this exact class: #9944, then #10109 this morning.
Cause
#10177 (the PostHog migration) added export const MCP_SERVER_NAME = "loopover" in src/mcp/server.ts:843. Both readers are in that same file — the handshake's serverInfo.name (line 863) and the analytics property builder (line 679) — so the export has no consumer.
Verified there is no cross-package reader: CHAT_GROUNDING_MCP_SERVER_NAME in packages/loopover-engine is a separate symbol, not this one re-exported.
Fix
Drop the export. No behaviour change — the constant and both call sites are untouched, and its doc comment (one constant so the handshake and the dashboards cannot disagree) still holds; it is simply module-local.
npm run typecheck clean, 1,339 MCP tests pass.
Worth noting
This is now the third time a merged PR has left main red on this specific checker, and each time it blocked the whole queue until someone noticed. #10146's escalation covers a workflow that stays red across runs, but dead-exports failing inside validate-code on main is a different signal — the PR that introduced it was green when it merged, because the export had a consumer in that PR's own diff or the checker's view differed pre-merge. Worth a separate look at why a merge can turn this red when the PR was green.
dead-exports:checkis red on a cleanmainagaintest:ciruns this, so every open PR inherits the failure and none can go green. Third instance of this exact class: #9944, then #10109 this morning.Cause
#10177 (the PostHog migration) added
export const MCP_SERVER_NAME = "loopover"insrc/mcp/server.ts:843. Both readers are in that same file — the handshake'sserverInfo.name(line 863) and the analytics property builder (line 679) — so theexporthas no consumer.Verified there is no cross-package reader:
CHAT_GROUNDING_MCP_SERVER_NAMEinpackages/loopover-engineis a separate symbol, not this one re-exported.Fix
Drop the
export. No behaviour change — the constant and both call sites are untouched, and its doc comment (one constant so the handshake and the dashboards cannot disagree) still holds; it is simply module-local.npm run typecheckclean, 1,339 MCP tests pass.Worth noting
This is now the third time a merged PR has left
mainred on this specific checker, and each time it blocked the whole queue until someone noticed. #10146's escalation covers a workflow that stays red across runs, butdead-exportsfailing insidevalidate-codeonmainis a different signal — the PR that introduced it was green when it merged, because the export had a consumer in that PR's own diff or the checker's view differed pre-merge. Worth a separate look at why a merge can turn this red when the PR was green.