Scaled-Tech-Consulting/Gitea-Tools
4
0
Fork 0
Code Issues 110 Pull Requests 12 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`
jcwalker3 removed the status:pr-open label 2026-07-21 13:47:00 -05:00
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
bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 jwalker (Regular User Account) superadmin (Admin Account) sysadmin (Regular User Account)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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