Detect stale MCP server runtime before mutation tools execute #531

New Issue

2026-07-08T04:07:17-05:00

jcwalker3 commented

2026-07-08 04:07:17 -05:00

Problem:
A reconciler attempted to close superseded PR #508, but the running reconciler MCP server was stale. The code on master already included merged behavior from #472 exempting reconciler close from #274 in the proper context, but the live server still enforced the old behavior and blocked the close. This forced operator reconnect/relaunch and delayed cleanup.

Risk:
LLM sessions may make correct decisions but be unable to perform authorized mutations because the running MCP server checkout/version is stale. Worse, a stale server may produce misleading capability or guard behavior that disagrees with current master.

Required behavior:

Mutation tools should expose or verify the MCP server code version/commit.
If the server checkout is behind the repository master required by the current workflow, mutation should fail with a clear stale-runtime diagnostic.
The diagnostic should include:
- running server commit/version
- expected or observed repository master commit
- tool/profile involved
- recommended reconnect/relaunch instruction
Reconciler close-pr flows should specifically detect when #274 behavior is stale relative to merged #472.
Canonical handoff comments should distinguish “decision made but mutation blocked by stale runtime” from “decision not yet made.”

Acceptance criteria:

Add tests for stale runtime detection before PR close mutation.
Add tests proving stale-runtime errors are clear and non-bypassable.
Add a helper command or diagnostic field that reports MCP server checkout/version.
Update reconciler handoff templates with a required runtime freshness proof before close/merge mutations.

Problem: A reconciler attempted to close superseded PR #508, but the running reconciler MCP server was stale. The code on master already included merged behavior from #472 exempting reconciler close from #274 in the proper context, but the live server still enforced the old behavior and blocked the close. This forced operator reconnect/relaunch and delayed cleanup. Risk: LLM sessions may make correct decisions but be unable to perform authorized mutations because the running MCP server checkout/version is stale. Worse, a stale server may produce misleading capability or guard behavior that disagrees with current master. Required behavior: 1. Mutation tools should expose or verify the MCP server code version/commit. 2. If the server checkout is behind the repository master required by the current workflow, mutation should fail with a clear stale-runtime diagnostic. 3. The diagnostic should include: - running server commit/version - expected or observed repository master commit - tool/profile involved - recommended reconnect/relaunch instruction 4. Reconciler close-pr flows should specifically detect when #274 behavior is stale relative to merged #472. 5. Canonical handoff comments should distinguish “decision made but mutation blocked by stale runtime” from “decision not yet made.” Acceptance criteria: - Add tests for stale runtime detection before PR close mutation. - Add tests proving stale-runtime errors are clear and non-bypassable. - Add a helper command or diagnostic field that reports MCP server checkout/version. - Update reconciler handoff templates with a required runtime freshness proof before close/merge mutations.

jcwalker3 commented

2026-07-08 12:40:29 -05:00

This issue is resolved by the changes in the branch fix/issue-531-mcp-eof-defect.
It implements active MCP runtime process checks and pre-flight gates in gitea_resolve_task_capability and _verify_role_mutation_workspace to detect stale or missing server processes.
This directly addresses the fail-closed requirements for the MCP connection EOF defect tracked under #544, ensuring that any disconnected or out-of-date namespaces block downstream mutations with a clear diagnostic.

This issue is resolved by the changes in the branch `fix/issue-531-mcp-eof-defect`. It implements active MCP runtime process checks and pre-flight gates in `gitea_resolve_task_capability` and `_verify_role_mutation_workspace` to detect stale or missing server processes. This directly addresses the fail-closed requirements for the MCP connection EOF defect tracked under #544, ensuring that any disconnected or out-of-date namespaces block downstream mutations with a clear diagnostic.

jcwalker3 referenced this issue

2026-07-08 12:40:29 -05:00

Investigate and resolve Gitea MCP namespace EOF defect #544

jcwalker3 referenced this issue

2026-07-08 12:45:55 -05:00

Detect stale MCP runtime before mutation tools execute #545

sysadmin referenced this issue

2026-07-08 13:04:54 -05:00

Detect stale MCP runtime before mutation tools execute #545

sysadmin referenced this issue

2026-07-08 13:04:54 -05:00

Detect stale MCP runtime before mutation tools execute #545