Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 73 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

MCP namespace EOF after server restart blocks registered Gitea tools from merger flow #543

New Issue
Closed
opened 2026-07-08 12:26:18 -05:00 by jcwalker3 · 5 comments
jcwalker3 commented 2026-07-08 12:26:18 -05:00
Owner
Copy Link
Copy Source

Context

During the PR #418 merge flow, the merger attempted to restart the Gitea MCP server so the newly landed tool gitea_adopt_merger_pr_lease would become available.

Observed facts

  • git fetch prgs confirmed local state was current with prgs/master.
  • Existing mcp_server.py processes were terminated.
  • IDE/MCP manager respawned backend server processes.
  • Direct Python inspection confirmed gitea_adopt_merger_pr_lease is compiled and registered in the FastMCP tool manager.
  • Basic MCP calls through the IDE client to gitea-reviewer and gitea-author, including gitea_whoami, failed with client is closing: EOF.
  • Another MCP server, context7, responded successfully, suggesting this is not a global MCP client failure.
  • Because the required adoption tool was unavailable through MCP, the merge flow was halted.

Problem

The server code can contain and register a tool while the IDE/MCP namespace remains unusable. This creates a false-ready state: local code inspection says the tool exists, but the actual workflow path cannot call it.

Required outcome

Add diagnostics, guardrails, and/or recovery tooling so MCP server restart success is validated through the same namespace path the workflow will use.

Acceptance criteria

  1. A health check exists for each configured Gitea MCP namespace: gitea-author, gitea-reviewer, gitea-merger, and any shared gitea-tools namespace.
  2. The health check verifies not only process existence but also successful tool invocation, such as gitea_whoami or gitea_list_profiles.
  3. The health check can verify whether a specific required tool is available through the live MCP client namespace, not only registered in Python.
  4. EOF failures are reported with actionable diagnostics: process PID, profile/env, config path, namespace name, and suggested restart/remediation steps.
  5. Merge workflows must block when the required live namespace call path is broken.
  6. A regression test or scripted proof reproduces the difference between “tool registered in FastMCP” and “tool callable through IDE/MCP namespace.”
  7. Documentation explains the correct recovery path when a namespace returns client is closing: EOF.

Canonical handoff

Do not retry PR #418 merge until the live MCP namespace can successfully call gitea_adopt_merger_pr_lease through the merger-authorized path. The issue is not whether the tool exists in code; the issue is that the active MCP client namespace cannot invoke it.

Requested labels

  • type:defect
  • area:mcp-runtime
  • area:ide-mcp-manager
  • process:merger
  • status:blocked
  • priority:high
## Context During the PR #418 merge flow, the merger attempted to restart the Gitea MCP server so the newly landed tool `gitea_adopt_merger_pr_lease` would become available. ## Observed facts - `git fetch prgs` confirmed local state was current with `prgs/master`. - Existing `mcp_server.py` processes were terminated. - IDE/MCP manager respawned backend server processes. - Direct Python inspection confirmed `gitea_adopt_merger_pr_lease` is compiled and registered in the `FastMCP` tool manager. - Basic MCP calls through the IDE client to `gitea-reviewer` and `gitea-author`, including `gitea_whoami`, failed with `client is closing: EOF`. - Another MCP server, `context7`, responded successfully, suggesting this is not a global MCP client failure. - Because the required adoption tool was unavailable through MCP, the merge flow was halted. ## Problem The server code can contain and register a tool while the IDE/MCP namespace remains unusable. This creates a false-ready state: local code inspection says the tool exists, but the actual workflow path cannot call it. ## Required outcome Add diagnostics, guardrails, and/or recovery tooling so MCP server restart success is validated through the same namespace path the workflow will use. ## Acceptance criteria 1. A health check exists for each configured Gitea MCP namespace: `gitea-author`, `gitea-reviewer`, `gitea-merger`, and any shared `gitea-tools` namespace. 2. The health check verifies not only process existence but also successful tool invocation, such as `gitea_whoami` or `gitea_list_profiles`. 3. The health check can verify whether a specific required tool is available through the live MCP client namespace, not only registered in Python. 4. EOF failures are reported with actionable diagnostics: process PID, profile/env, config path, namespace name, and suggested restart/remediation steps. 5. Merge workflows must block when the required live namespace call path is broken. 6. A regression test or scripted proof reproduces the difference between “tool registered in FastMCP” and “tool callable through IDE/MCP namespace.” 7. Documentation explains the correct recovery path when a namespace returns `client is closing: EOF`. ## Canonical handoff Do not retry PR #418 merge until the live MCP namespace can successfully call `gitea_adopt_merger_pr_lease` through the merger-authorized path. The issue is not whether the tool exists in code; the issue is that the active MCP client namespace cannot invoke it. ## Requested labels - `type:defect` - `area:mcp-runtime` - `area:ide-mcp-manager` - `process:merger` - `status:blocked` - `priority:high`
jcwalker3 commented 2026-07-09 09:46:43 -05:00
Author
Owner
Copy Link
Copy Source

Gap assessment vs #531/#545 (what landed) — 0 of 7 AC fully met

#531/#545 (5ad764b + be0123c) landed test_mcp_conn.py, tests/test_mcp_stale_runtime.py, and _check_mcp_runtimes_diagnostics. Mapped against this issue's 7 acceptance criteria on master, they do not close it.

Core finding

The landed code detects the wrong failure mode. _check_mcp_runtimes_diagnostics (gitea_mcp_server.py:9290) checks OS-process staleness via ps — is a process running, is its start time older than the code mtime. This issue's defect is process alive + tool registered in FastMCP, but the live IDE/MCP namespace returns client is closing: EOF. The diagnostic never invokes a tool through the client namespace, so it cannot observe the EOF case at all. Right instinct, wrong path validated.

AC scorecard

AC Requirement Status Evidence / gap
1 Health check per namespace (author/reviewer/merger/tools) PARTIAL :9290 is a ps process check keyed on profile match — not a per-namespace health probe across the 4 named namespaces.
2 Verify tool invocation, not just process alive GAP (prod) Only test_mcp_conn.py does a real handshake; it is a standalone script, not wired into any production check. Prod path is ps-only.
3 Verify a specific required tool callable through the live client namespace GAP Nothing checks "is gitea_adopt_merger_pr_lease callable through the merger namespace." The registered-vs-callable distinction is exactly what's missing.
4 EOF reported w/ PID, profile/env, config path, namespace, remediation PARTIAL Reason strings (:9339/:9354/:9359) give restart guidance + a touch <config> hint + profile list. Missing structured PID, env/profile detail, namespace name; and they only fire on the stale-process branch — never on EOF.
5 Merge blocks when live path broken COVERED (stale case only) Two prod callers block — _verify_role_mutation_workspace (:725 → raise RuntimeError) and gitea_resolve_task_capability (:9531 → restart_required=True). But they trip on stale process, not EOF, so this issue's actual scenario still wouldn't block.
6 Test proving "registered in FastMCP" ≠ "callable through IDE namespace" GAP tests/test_mcp_stale_runtime.py has one test (test_stale_and_missing_runtimes), mocking ps/getpid/getmtime for process-staleness reasons only. test_mcp_conn.py has no def test_*, is not pytest-collected, and asserts nothing.
7 Docs: client is closing: EOF recovery path GAP Zero hits for "client is closing" / EOF-recovery across all .md and .py. No recovery doc exists.

Secondary defects in what landed

  • test_mcp_conn.py:106 hardcodes /Users/<user>/.gemini/config/mcp_config.json — machine-specific, not CI-runnable.
  • test_mcp_conn.py tests only gitea-author + gitea-reviewer — not merger/tools.
  • Both prod checks (:702, :9530) short-circuit under PYTEST_CURRENT_TEST unless GITEA_FORCE_MCP_RUNTIME_CHECK is set → normal test runs skip the live check.
  • Untested reason branches: :9309 (ps-failure), :9379 (all-stale-running).

Remaining work to close #543 (five items)

  1. Live namespace probe (AC 1/2/3) — per-namespace helper that calls a cheap tool (gitea_whoami/gitea_list_profiles) through the client and classifies OK / EOF / timeout / tool-missing. This is the missing piece; distinct from the ps staleness check — both should run.
  2. Callable-through-client check (AC 3) — given namespace + tool name, confirm callable-through-client, not just in FastMCP._tool_manager.
  3. EOF-aware blocking (AC 4/5) — structured reason payload (PID, profile/env, config path, namespace, remediation) and make the merge-path guard trip on EOF, not only stale-process.
  4. Pytest-collected regression test (AC 6) — assert registered-≠-callable (tool in registry but namespace probe returns EOF → check fails); path-independent (fix hardcoded config path or inject config).
  5. Recovery docs (AC 7) — docs/ page: symptom client is closing: EOF, cause, correct restart/reconnect sequence.

Relationship to #544

#544 is the investigation twin of this issue, not a separate implementation track. Its five asks — (1) inspect IDE MCP config/env/lifecycle, (2) add a live namespace health-check script, (3) diagnose root cause, (4) block the merger workflow with diagnostics, (5) add test coverage — are a strict subset of #543's remaining work above. #544 should be treated as folded into / dependent on #543; closing items 1–5 here resolves it.

Not proposing to close either issue — flagging the dependency for triage.

## Gap assessment vs #531/#545 (what landed) — 0 of 7 AC fully met #531/#545 (`5ad764b` + `be0123c`) landed `test_mcp_conn.py`, `tests/test_mcp_stale_runtime.py`, and `_check_mcp_runtimes_diagnostics`. Mapped against this issue's 7 acceptance criteria on `master`, they do **not** close it. ### Core finding The landed code detects the **wrong failure mode**. `_check_mcp_runtimes_diagnostics` (`gitea_mcp_server.py:9290`) checks **OS-process staleness** via `ps` — is a process running, is its start time older than the code mtime. This issue's defect is **process alive + tool registered in FastMCP, but the live IDE/MCP namespace returns `client is closing: EOF`**. The diagnostic never invokes a tool *through the client namespace*, so it cannot observe the EOF case at all. Right instinct, wrong path validated. ### AC scorecard | AC | Requirement | Status | Evidence / gap | |----|-------------|--------|----------------| | 1 | Health check per namespace (author/reviewer/merger/tools) | **PARTIAL** | `:9290` is a `ps` process check keyed on profile match — not a per-namespace health probe across the 4 named namespaces. | | 2 | Verify tool *invocation*, not just process alive | **GAP (prod)** | Only `test_mcp_conn.py` does a real handshake; it is a standalone script, not wired into any production check. Prod path is `ps`-only. | | 3 | Verify a *specific required tool* callable through the live client namespace | **GAP** | Nothing checks "is `gitea_adopt_merger_pr_lease` callable through the merger namespace." The registered-vs-callable distinction is exactly what's missing. | | 4 | EOF reported w/ PID, profile/env, config path, namespace, remediation | **PARTIAL** | Reason strings (`:9339`/`:9354`/`:9359`) give restart guidance + a `touch <config>` hint + profile list. Missing structured **PID**, **env/profile detail**, **namespace name**; and they only fire on the stale-process branch — never on EOF. | | 5 | Merge blocks when live path broken | **COVERED (stale case only)** | Two prod callers block — `_verify_role_mutation_workspace` (`:725` → `raise RuntimeError`) and `gitea_resolve_task_capability` (`:9531` → `restart_required=True`). But they trip on *stale process*, not EOF, so this issue's actual scenario still wouldn't block. | | 6 | Test proving "registered in FastMCP" ≠ "callable through IDE namespace" | **GAP** | `tests/test_mcp_stale_runtime.py` has one test (`test_stale_and_missing_runtimes`), mocking `ps`/`getpid`/`getmtime` for process-staleness reasons only. `test_mcp_conn.py` has no `def test_*`, is not pytest-collected, and asserts nothing. | | 7 | Docs: `client is closing: EOF` recovery path | **GAP** | Zero hits for "client is closing" / EOF-recovery across all `.md` and `.py`. No recovery doc exists. | ### Secondary defects in what landed - `test_mcp_conn.py:106` hardcodes `/Users/<user>/.gemini/config/mcp_config.json` — machine-specific, not CI-runnable. - `test_mcp_conn.py` tests only `gitea-author` + `gitea-reviewer` — not merger/tools. - Both prod checks (`:702`, `:9530`) short-circuit under `PYTEST_CURRENT_TEST` unless `GITEA_FORCE_MCP_RUNTIME_CHECK` is set → normal test runs skip the live check. - Untested reason branches: `:9309` (ps-failure), `:9379` (all-stale-running). ### Remaining work to close #543 (five items) 1. **Live namespace probe** (AC 1/2/3) — per-namespace helper that calls a cheap tool (`gitea_whoami`/`gitea_list_profiles`) *through the client* and classifies OK / EOF / timeout / tool-missing. This is the missing piece; distinct from the `ps` staleness check — both should run. 2. **Callable-through-client check** (AC 3) — given namespace + tool name, confirm callable-through-client, not just `in FastMCP._tool_manager`. 3. **EOF-aware blocking** (AC 4/5) — structured reason payload (PID, profile/env, config path, namespace, remediation) and make the merge-path guard trip on EOF, not only stale-process. 4. **Pytest-collected regression test** (AC 6) — assert registered-≠-callable (tool in registry but namespace probe returns EOF → check fails); path-independent (fix hardcoded config path or inject config). 5. **Recovery docs** (AC 7) — `docs/` page: symptom `client is closing: EOF`, cause, correct restart/reconnect sequence. ### Relationship to #544 **#544 is the investigation twin of this issue, not a separate implementation track.** Its five asks — (1) inspect IDE MCP config/env/lifecycle, (2) add a live namespace health-check script, (3) diagnose root cause, (4) block the merger workflow with diagnostics, (5) add test coverage — are a strict subset of #543's remaining work above. #544 should be treated as **folded into / dependent on #543**; closing items 1–5 here resolves it. _Not proposing to close either issue — flagging the dependency for triage._
jcwalker3 added the status:in-progress label 2026-07-09 09:50:58 -05:00
jcwalker3 commented 2026-07-09 09:50:59 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #543 - branch: pending - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation
jcwalker3 added status:pr-open and removed status:in-progress labels 2026-07-09 12:10:51 -05:00
sysadmin commented 2026-07-09 14:59:23 -05:00
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: status:pr-open — additional live reviewer-namespace transport failure evidence

WHO_IS_NEXT: reviewer

NEXT_ACTION: Restart PR #596's canonical reviewer workflow from identity/live-state preflight and acquire a fresh reviewer lease before validation.

NEXT_PROMPT:

Gitea reviewer task. Invoke gitea-workflow first. Retry the full review of PR #596 for Issue #539 from the beginning. Verify live identity and PR head, create or safely use an isolated branches/ reviewer worktree, acquire a fresh reviewer lease, run the required validation, and submit a formal review decision. Do not reuse stale validation or lease state from the blocked run, and do not merge.

WHAT_HAPPENED:

  • Review target: PR #596 for Issue #539.
  • Verified reviewer identity: sysadmin / prgs-reviewer.
  • Live PR state before validation: open, mergeable, head 2941ec529c1e9a27b46ea66723df4bd34d7f3c9f.
  • Isolated reviewer worktree: branches/review-fix-issue-539-role-boundary-hard-stops, detached at the candidate head.
  • Mandatory gate gitea_acquire_reviewer_pr_lease failed with Transport closed.
  • The canonical review workflow stopped before diff validation and tests.
  • No formal review, merge, source edit, raw API/curl call, direct import, temporary script, MCP-internal manipulation, in-memory restoration, or fallback occurred.
  • The worktree had been created before the lease gate failed; no reviewer lease was acquired.

WHY: This is another live example of the #543/#544 failure class: the gitea-reviewer namespace became non-callable through the active transport during a mandatory canonical workflow gate. It extends the tracker evidence beyond merger adoption because reviewer lease acquisition can fail with the same transport-closed/EOF class.

RELATED_PRS: #587 implements the #543/#544 transport diagnostics and blocking path. #596 is the review blocked by this occurrence.

BLOCKERS: The original PR #596 review remains blocked and cannot resume from stale state. This evidence-update task can currently call the MCP comment path, but a retry still must prove transport health and acquire a new reviewer lease.

VALIDATION: Current-session MCP reads verified Issue #543 open with status:pr-open; Issue #544 open; PR #587 open and mergeable, closing #543/#544; PR #596 open and mergeable at 2941ec529c1e9a27b46ea66723df4bd34d7f3c9f; gitea.issue.comment resolved for sysadmin / prgs-reviewer. No code validation was run in this update-only task.

LAST_UPDATED_BY: sysadmin / prgs-reviewer

## Canonical Issue State STATE: `status:pr-open` — additional live reviewer-namespace transport failure evidence WHO_IS_NEXT: reviewer NEXT_ACTION: Restart PR #596's canonical reviewer workflow from identity/live-state preflight and acquire a fresh reviewer lease before validation. NEXT_PROMPT: ```text Gitea reviewer task. Invoke gitea-workflow first. Retry the full review of PR #596 for Issue #539 from the beginning. Verify live identity and PR head, create or safely use an isolated branches/ reviewer worktree, acquire a fresh reviewer lease, run the required validation, and submit a formal review decision. Do not reuse stale validation or lease state from the blocked run, and do not merge. ``` WHAT_HAPPENED: - Review target: PR #596 for Issue #539. - Verified reviewer identity: `sysadmin / prgs-reviewer`. - Live PR state before validation: open, mergeable, head `2941ec529c1e9a27b46ea66723df4bd34d7f3c9f`. - Isolated reviewer worktree: `branches/review-fix-issue-539-role-boundary-hard-stops`, detached at the candidate head. - Mandatory gate `gitea_acquire_reviewer_pr_lease` failed with `Transport closed`. - The canonical review workflow stopped **before diff validation and tests**. - No formal review, merge, source edit, raw API/curl call, direct import, temporary script, MCP-internal manipulation, in-memory restoration, or fallback occurred. - The worktree had been created before the lease gate failed; no reviewer lease was acquired. WHY: This is another live example of the #543/#544 failure class: the `gitea-reviewer` namespace became non-callable through the active transport during a mandatory canonical workflow gate. It extends the tracker evidence beyond merger adoption because reviewer lease acquisition can fail with the same transport-closed/EOF class. RELATED_PRS: #587 implements the #543/#544 transport diagnostics and blocking path. #596 is the review blocked by this occurrence. BLOCKERS: The original PR #596 review remains blocked and cannot resume from stale state. This evidence-update task can currently call the MCP comment path, but a retry still must prove transport health and acquire a new reviewer lease. VALIDATION: Current-session MCP reads verified Issue #543 open with `status:pr-open`; Issue #544 open; PR #587 open and mergeable, closing #543/#544; PR #596 open and mergeable at `2941ec529c1e9a27b46ea66723df4bd34d7f3c9f`; `gitea.issue.comment` resolved for `sysadmin / prgs-reviewer`. No code validation was run in this update-only task. LAST_UPDATED_BY: `sysadmin / prgs-reviewer`
sysadmin commented 2026-07-09 15:15:13 -05:00
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: status:pr-open — host/client reviewer-namespace recurrence and recovery proof

WHO_IS_NEXT: reviewer

NEXT_ACTION: Start a fresh canonical review workflow for PR #587; do not reuse any state from the transport-blocked sessions.

NEXT_PROMPT:

Gitea reviewer task. Invoke gitea-workflow first. Review PR #587 for Issues #543/#544 from the beginning using live Gitea state, a fresh reviewer lease, and an isolated branches/ worktree. Confirm the reviewer namespace remains stable through lease acquisition and review submission. Do not merge.

WHAT_HAPPENED:

  • After the PR #596 lease failure recorded in comment #8594, a later recovery/triage attempt failed on its first gitea-reviewer.mcp_get_control_plane_guide call with Transport closed.
  • A subsequent host/client recovery check also failed immediately on gitea-reviewer.gitea_whoami(remote="prgs") with Transport closed.
  • No approved reconnect control was exposed inside the task session, so no process, config, alternate namespace, API, or internal fallback was used.
  • After host/client reconnection, the prescribed stability checks succeeded in order:
    1. gitea_whoami(remote="prgs") -> sysadmin / prgs-reviewer
    2. mcp_get_control_plane_guide -> Gitea-Tools resolved, reviewer profile verified
    3. gitea_resolve_task_capability(task="review_pr") -> allowed, no restart/stop required
    4. repeated gitea_whoami(remote="prgs") -> succeeded
  • A further identity check before this comment also succeeded.

WHY: The namespace failure occurred before Gitea live triage and was recoverable only from the host/client layer. This is the exact process-alive/client-transport-unavailable class tracked by #543/#544, now observed on control-plane guidance and identity verification as well as reviewer lease acquisition.

RELATED_PRS: #587 remains the open implementation PR for #543/#544. PR #596 remains a separate review target and was not retried in this recovery task.

BLOCKERS: The immediate transport outage is cleared for repeated read and capability calls. PR #587 still requires an independent canonical review; no review lease or review decision was attempted in this recovery task.

VALIDATION: Live reads after reconnect verified #543 open with status:pr-open, #544 open, and PR #587 open and mergeable at 653a728bb5fcccc68fc6e7d609240f04531fcdd8 with no formal reviews. Open-PR inventory returned five PRs with has_more=false, is_final_page=true, and inventory_complete=true.

LAST_UPDATED_BY: sysadmin / prgs-reviewer

## Canonical Issue State STATE: `status:pr-open` — host/client reviewer-namespace recurrence and recovery proof WHO_IS_NEXT: reviewer NEXT_ACTION: Start a fresh canonical review workflow for PR #587; do not reuse any state from the transport-blocked sessions. NEXT_PROMPT: ```text Gitea reviewer task. Invoke gitea-workflow first. Review PR #587 for Issues #543/#544 from the beginning using live Gitea state, a fresh reviewer lease, and an isolated branches/ worktree. Confirm the reviewer namespace remains stable through lease acquisition and review submission. Do not merge. ``` WHAT_HAPPENED: - After the PR #596 lease failure recorded in comment #8594, a later recovery/triage attempt failed on its first `gitea-reviewer.mcp_get_control_plane_guide` call with `Transport closed`. - A subsequent host/client recovery check also failed immediately on `gitea-reviewer.gitea_whoami(remote="prgs")` with `Transport closed`. - No approved reconnect control was exposed inside the task session, so no process, config, alternate namespace, API, or internal fallback was used. - After host/client reconnection, the prescribed stability checks succeeded in order: 1. `gitea_whoami(remote="prgs")` -> `sysadmin / prgs-reviewer` 2. `mcp_get_control_plane_guide` -> Gitea-Tools resolved, reviewer profile verified 3. `gitea_resolve_task_capability(task="review_pr")` -> allowed, no restart/stop required 4. repeated `gitea_whoami(remote="prgs")` -> succeeded - A further identity check before this comment also succeeded. WHY: The namespace failure occurred before Gitea live triage and was recoverable only from the host/client layer. This is the exact process-alive/client-transport-unavailable class tracked by #543/#544, now observed on control-plane guidance and identity verification as well as reviewer lease acquisition. RELATED_PRS: #587 remains the open implementation PR for #543/#544. PR #596 remains a separate review target and was not retried in this recovery task. BLOCKERS: The immediate transport outage is cleared for repeated read and capability calls. PR #587 still requires an independent canonical review; no review lease or review decision was attempted in this recovery task. VALIDATION: Live reads after reconnect verified #543 open with `status:pr-open`, #544 open, and PR #587 open and mergeable at `653a728bb5fcccc68fc6e7d609240f04531fcdd8` with no formal reviews. Open-PR inventory returned five PRs with `has_more=false`, `is_final_page=true`, and `inventory_complete=true`. LAST_UPDATED_BY: `sysadmin / prgs-reviewer`
sysadmin commented 2026-07-09 15:31:25 -05:00
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: status:pr-open — repeated post-recovery transport instability

WHO_IS_NEXT: reviewer

NEXT_ACTION: Continue the fresh canonical review of PR #587 only while the reviewer namespace remains stable through lease acquisition and review submission.

NEXT_PROMPT:

Continue the current canonical PR #587 review at head 653a728bb5fcccc68fc6e7d609240f04531fcdd8 from the isolated reviewer worktree. Acquire a fresh reviewer lease, validate the unmodified head, and submit one formal review decision. Stop immediately on any Transport closed recurrence. Do not merge.

WHAT_HAPPENED:

  • Comment #8627 recorded an earlier control-plane/identity outage followed by successful recovery probes.
  • The next fresh PR #587 review attempt then failed on its first mcp_get_control_plane_guide call with Transport closed.
  • A following recovery-gated attempt failed immediately on its first gitea_whoami(remote="prgs") call with Transport closed.
  • No reviewer lease, validation, review, merge, alternate namespace, API fallback, process manipulation, or configuration change occurred in those blocked attempts.
  • In this retry, the required sequence succeeded: whoami, control-plane guide, review_pr capability resolution, and repeated whoami.
  • The canonical workflow loaded with a clean boundary, live state verified PR #587 open/mergeable at 653a728bb5fcccc68fc6e7d609240f04531fcdd8, and a fresh detached reviewer worktree was created at branches/review-feat-issue-543-mcp-namespace-health-check.

WHY: Recovery probes alone did not prove session longevity; the namespace closed again on the first subsequent canonical call. This recurrence directly supports #543's requirement to validate the live client path across real workflow transitions, not only isolated health probes.

RELATED_PRS: #587 is the active implementation PR for #543/#544. PR #596 and PR #592 were not touched.

BLOCKERS: No immediate blocker at comment time. Any further Transport closed result must terminate the review and be treated as another #543 recurrence.

VALIDATION: Current-session MCP reads verified #543/#544 open, PR #587 open and mergeable, no prior formal review, no active reviewer lease, reviewer identity sysadmin / prgs-reviewer, and complete open-PR pagination. Local checks verified the detached reviewer worktree has no status entries and matches the live PR head.

LAST_UPDATED_BY: sysadmin / prgs-reviewer

## Canonical Issue State STATE: `status:pr-open` — repeated post-recovery transport instability WHO_IS_NEXT: reviewer NEXT_ACTION: Continue the fresh canonical review of PR #587 only while the reviewer namespace remains stable through lease acquisition and review submission. NEXT_PROMPT: ```text Continue the current canonical PR #587 review at head 653a728bb5fcccc68fc6e7d609240f04531fcdd8 from the isolated reviewer worktree. Acquire a fresh reviewer lease, validate the unmodified head, and submit one formal review decision. Stop immediately on any Transport closed recurrence. Do not merge. ``` WHAT_HAPPENED: - Comment #8627 recorded an earlier control-plane/identity outage followed by successful recovery probes. - The next fresh PR #587 review attempt then failed on its first `mcp_get_control_plane_guide` call with `Transport closed`. - A following recovery-gated attempt failed immediately on its first `gitea_whoami(remote="prgs")` call with `Transport closed`. - No reviewer lease, validation, review, merge, alternate namespace, API fallback, process manipulation, or configuration change occurred in those blocked attempts. - In this retry, the required sequence succeeded: `whoami`, control-plane guide, `review_pr` capability resolution, and repeated `whoami`. - The canonical workflow loaded with a clean boundary, live state verified PR #587 open/mergeable at `653a728bb5fcccc68fc6e7d609240f04531fcdd8`, and a fresh detached reviewer worktree was created at `branches/review-feat-issue-543-mcp-namespace-health-check`. WHY: Recovery probes alone did not prove session longevity; the namespace closed again on the first subsequent canonical call. This recurrence directly supports #543's requirement to validate the live client path across real workflow transitions, not only isolated health probes. RELATED_PRS: #587 is the active implementation PR for #543/#544. PR #596 and PR #592 were not touched. BLOCKERS: No immediate blocker at comment time. Any further `Transport closed` result must terminate the review and be treated as another #543 recurrence. VALIDATION: Current-session MCP reads verified #543/#544 open, PR #587 open and mergeable, no prior formal review, no active reviewer lease, reviewer identity `sysadmin / prgs-reviewer`, and complete open-PR pagination. Local checks verified the detached reviewer worktree has no status entries and matches the live PR head. LAST_UPDATED_BY: `sysadmin / prgs-reviewer`
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
allocator
Controller-owned work allocator
 anti-stomp
Prevent concurrent LLM session stomping
 architecture
Architecture / structural design
 bug
chore
codex
OpenAI Codex client / workflow session surface
 concurrency
Concurrent session safety
 contamination
Workflow or session contamination incident
 control-plane
MCP control-plane coordination and allocation authority
 dashboard
MCP operational dashboard/queue view
 database
Internal coordination storage (SQLite/Postgres)
 design
Design / investigation, no implementation
 documentation
Docs / runbooks
 enhancement
New feature or improvement
 gitea
Gitea MCP workflow
 glitchtip
GlitchTip integration
 important
incident
Operational or process incident requiring durable audit trail
 incident-bridge
Sentry-to-Gitea incident bridging
 integration
Integration testing
 jenkins
Jenkins integration
 labels
Label taxonomy management
 leases
Lease adopt/release/expire lifecycle
 mcp
MCP server / tooling
 mcp-health
MCP namespace and runtime health
 mcp-menu
MCP menu surface
 multi-project
Work spanning multiple monitoring projects or Gitea repos
 mutating
Mutating action; requires gating
 nice-to-have
observability
Observability, metrics, traces, error reporting
 portability
Cross-platform / portability
 preflight
Shared preflight gates before mutation
 protected-branch
Protected branch / stable-branch policy concern
 queue
Work queue visibility and allocation
 read-only
Read-only, no mutation
 reconnect
MCP client reconnect/reload recovery path
 recovery
Recovery paths for stale/foreign leases
 refactor
Code refactor / restructure
 release
Release / versioning
 reliability
Reliability / failure handling
 resumable-review
Persist and resume prepared review verdicts across sessions
 reviewer
Reviewer workflow tooling
 roadmap
Roadmap / umbrella issue
 safety
Safety rails and fail-closed mutation guards
 security
Security / trust boundary
 self-hosted
Self-hosted infrastructure integration
 sentry
Sentry error monitoring integration
 stale-runtime
Stale backend daemon / runtime-vs-master parity failures
 status:blocked
Issue is blocked
 status:in-progress
Issue is being worked on
 status:pr-open
Issue has an open pull request
 status:ready
Issue is ready for work
 terminal-lock
Terminal review lock (#332) path
 testing
Tests / test coverage
 tracker
Issue tracker hygiene / meta
 type:bug
Bug or defect
 type:feature
Feature or enhancement
 type:feature
Feature or enhancement
 type:guardrail
Safety gate or guardrail
 visibility
Workflow state visibility for LLMs/operators
 workflow
Cross-tool workflow
 workflow-hardening
LLM workflow coordination hardening
 workflow-hardening
LLM workflow coordination hardening
No labels status:pr-open
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#543