Repository navigation
chore(deps)(deps): update mcp requirement from <2.0,>=1.27 to >=1.27,<3.0 - #316
Merged
Merged
Conversation
Updates the requirements on [mcp](https://github.com/modelcontextprotocol/python-sdk) to permit the latest version. - [Release notes](https://github.com/modelcontextprotocol/python-sdk/releases) - [Changelog](https://github.com/modelcontextprotocol/python-sdk/blob/main/RELEASE.md) - [Commits](modelcontextprotocol/python-sdk@v1.27.0...v2.0.0) --- updated-dependencies: - dependency-name: mcp dependency-version: 2.0.0 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
mlorentedev
added a commit
that referenced
this pull request
Aug 7, 2026
Bookkeeping reconciliation found while auditing what was left half-done. Four independent inconsistencies; no behaviour change except the workflow condition. ## ADR-005 was overdue for supersession by its own rule ADR-005 carries this note from 2026-05-30: > "When ADR-011 is accepted, this ADR's 'Stay on Option A' recommendation is superseded." ADR-011 was accepted on 2026-05-31. ADR-005 still read `status: proposed`. Now marked superseded, pointing at ADR-011; the Option A/B comparison stays as context since it is still the reasoning behind the current transport. ## HIVE-118 contradicted itself `tasks.md` line 10 announces **"STATUS: FROZEN (2026-05-31). ADR-011 is accepted; the design is locked."** Six lines below, `- [ ] ADR-011 authored + merged — gating` was still unchecked, as was `- [ ] ADR-011 merged + ADR-005 amended to point at it`. Both ticked. This one mattered beyond tidiness: reading the unchecked gate is what led me to report, incorrectly, that the daemon's gating ADR had never been merged. ## HIVE-176 had no frontmatter Every sibling spec carries the `id` / `type` / `status` / `template_version` block; this one had none. Added with `status: implementing` — its tasks are 0/12 and issue #176 is open, so it is **active work, not a stale artifact awaiting archive**. (I had it on a cleanup list as "never archived"; checking the task state showed that was wrong.) ## add-to-project.yml excluded bot PRs but not bot issues ```yaml if: github.event_name == 'issues' || (… user.login != 'dependabot[bot]') ``` `github.event_name == 'issues'` short-circuits the whole expression, so the bot exclusion only ever applied to pull requests. A bot-authored **issue** would land on the board regardless. Latent today — Dependabot opens no issues by default — but live the moment Dependabot security alerts are configured to file them, or any other bot starts opening issues. The exclusion now applies to both event types via `github.event.sender.login`, with the PR-specific fork and author checks kept intact. The condition is only used in an `if:` expression, evaluated by the Actions expression engine rather than interpolated into a shell command, so this introduces no injection surface. ## Not included `uv.lock` shows unrelated resolver churn plus the `mcp` specifier catching up to `>=1.27,<3.0` from #316. Left out to keep this focused. Worth a separate look: that `<3.0` cap is the one whose guard comment still says "Cap at <2.0 … bump the upper bound only after auditing the `_compat` shim", and `mcp` 2.0.0 is published and does break hive (`McpError` → `MCPError`). It is currently masked because `fastmcp-slim` requires `mcp<2.0` transitively.
This was referenced Aug 8, 2026
mlorentedev
added a commit
that referenced
this pull request
Aug 8, 2026
Docs-only. `AGENTS.md` is the first file every agent reads in this repo, and its account of `src/hive/_compat.py` had drifted from the code on three points. All three were verified against the source and against the upstream trackers before writing. ## 1. Wrong patch target AGENTS.md said the shim patches `RequestResponder.__exit__` to swallow an anyio `CancelledError`. It patches **`RequestResponder.respond`**, to short-circuit the upstream `assert not self._completed`. The `__exit__` patch was **removed** — `_compat.py`'s own docstring records why: the issue-#75 symptom stopped reproducing on `mcp >= 1.27`, because `Server._handle_request` catches the in-flight cancellation before it can reach `__exit__`. ## 2. Wrong upstream tracker, and a stale instruction AGENTS.md pointed at [python-sdk#2610](modelcontextprotocol/python-sdk#2610) with an escalation deadline of 2026-06-12 and an instruction to port the fix ourselves. The shim's fate is actually tied to [**#2416**](modelcontextprotocol/python-sdk#2416) — open, maintainer-bot-confirmed on both `main` and `origin/v1.x`, with a contributor volunteering to fix it on 2026-07-11 (and our own reproduction already posted there on 2026-06-19). Meanwhile #2610 already has an open upstream fix PR, [#2624](modelcontextprotocol/python-sdk#2624). Porting it ourselves would duplicate existing work. **This matters beyond the docs:** #127 is scoped as "if #2610 is still silent, port the fix as our own upstream PR". That premise no longer holds. #127 is commented separately rather than being silently rescoped here. ## 3. Stale pin, and a guard that no longer holds AGENTS.md quoted `mcp>=1.26,<2.0`, with the rationale that a narrow cap stops a major `RequestResponder` refactor from silently breaking the shim. The actual constraint is now `mcp>=1.27,<3.0` (widened by #316). `<3.0` admits `mcp` 2.x — precisely the major boundary the cap existed to exclude. I recorded this as a **lost guard** rather than silently re-narrowing the pin: `apply()` degrades loudly (logs a warning and no-ops) rather than silently, so this is not a live bug, and re-narrowing a dependency range is a decision with its own consequences, not a docs edit. Flagging it for a deliberate call. ## Verification No code changed, so no test impact. The three claims were checked against `src/hive/_compat.py` (docstring + `apply()`), `pyproject.toml:49`, and the three upstream trackers via the GitHub API.
This was referenced Aug 8, 2026
mlorentedev
added a commit
that referenced
this pull request
Aug 8, 2026
) Implements the decision recorded in #342. ## The finding `pyproject.toml` stated the constraint and its justification in the same block, and they contradicted each other: ```toml # Cap at <2.0 so a deliberate review happens before adopting # any new major release. ... "mcp>=1.27,<3.0", ``` #316 widened the constraint and left the rationale untouched, so the file documented a guard it no longer had. ## Why the guard matters `src/hive/_compat.py` patches a **private** method on `mcp.shared.session.RequestResponder`. Private internals carry no compatibility promise across a major release, and `<3.0` admits the entire 2.x line — precisely the boundary the original cap was written to exclude. The shim is self-gated and degrades quietly if the symbols move. That is a real mitigation but the wrong one to rely on here: quiet degradation means the cancel-race crash (#75) returns with no failing build to announce it. The cap is what converts a silent regression into a deliberate review. ## Two further corrections in the same block This is the drift #336 fixed in `AGENTS.md`, which was present in `pyproject.toml` too: - It listed `__exit__`, `_on_complete` and `_cancel_scope` among the patched internals. **None are touched today.** The `__exit__` companion patch was removed once the symptom stopped reproducing on `mcp >= 1.27` (where `Server._handle_request` catches the cancellation first), and the other two are never referenced. What the shim actually does is patch `respond` and read `_completed` and `_entered` — verified against the module, not the comment. - It named [python-sdk#2610](modelcontextprotocol/python-sdk#2610) as the upstream tracker. The live one is [#2416](modelcontextprotocol/python-sdk#2416); #2610 is the sibling `__exit__` leak, already masked upstream and carrying its own fix PR (#2624). See #127. ## Verification - `mcp` resolves to **1.28.1** — comfortably inside the narrowed cap, so nothing is downgraded. - The `uv.lock` diff is the specifier line alone (`+1/-1`); no collateral resolution churn. - `make check` green locally: ruff, `mypy --strict`, **830 passed, 2 skipped**. Sequenced after #338 as planned, so the two do not regenerate `uv.lock` from separate branches. Closes #342. Refs #316, #336, #127.
mlorentedev
added a commit
that referenced
this pull request
Aug 8, 2026
Closes #333. Docs-only. ## What #333 asked, and what reality turned out to be The ticket flagged 6 unresolved `[AGENT-DRAFT]` markers in a spec whose work is already in production. All 6 are resolved. But the more useful outcome is the status reconciliation: **this spec is `verifying`, not archivable** — and for two concrete reasons that were not previously written down anywhere. The A3 mechanism did ship — #290, #294, #302 → `src/hive/_runtime.py`, **25 passing tests**, `hive self-upgrade [version]` wired at `server.py:653`. It is load-bearing, not experimental: `_service._current_layout_exec()` resolves through the layout, and ADR-019 builds the launcher decision on it. ## The two gates that block archiving 1. **AC4 — real non-admin Windows re-validation has never been performed.** The 2026-06-24 hardware pass was the **feasibility spike**, run before any code existed. The shipped implementation has only ever run on CI (Linux + Windows runners) and a Linux dev box. Blocked in practice: that machine is in the orphaned-trampoline state (dotfiles#791). 2. **AC1's `hive --version` clause cannot be verified** — no launcher is on `PATH`. Acceptance criteria are now marked against **evidence rather than intent**, using `[~]` for the two that are partially met, each with the reason. ## The load-bearing correction `tasks.md` asserted: > The launcher (`~/.local/bin`) + supervisor already resolve through `current` The supervisor half is true. **The launcher half was false** — nothing ever installed one, so after a successful upgrade `current` pointed at a working venv that no shell could find. That false claim is *why this spec's own "+ own launcher" promise went unnoticed*, until it resurfaced as **#328** months later. `~/.local/bin` is also the wrong directory now: [ADR-019](https://github.com/mlorentedev/hive/blob/master/docs/adr/adr-019-launcher-ownership.md) chose `%LOCALAPPDATA%\hive\bin` and explicitly forbids hive touching `~/.local/bin`. Both facts are recorded at the point of the claim, and the launcher deliverable is reassigned to HIVE-328 in `Out of scope` — so two specs no longer claim the same thing. ## The two remaining Risks drafts Resolved from **existing evidence**, not fresh analysis: - **"The supervisor holds the lock"** → this is the risk A3 was chosen to *dissolve*, not manage. Junction ops touch only the reparse point, never the locked targets. The spike proved it: `current` repointed from `versions/1.41.5` to `1.41.6` while an exclusive `FileShare.None` lock was held on `1.41.5/core.pyd`, no "Access is denied". No stop/restart needed, so no window where the MCP is dead. - **"Windows-only, hardware-gated"** → split deliberately. The *scoping* is settled (POSIX has no in-use-file lock, so Linux keeps `uv tool` — dotfiles AI-028 AC6, same conclusion ADR-019 reached). The *hardware gate* is *not* settled and is now AC4 above, rather than being quietly absorbed into a resolved bullet. ## verification.md Replaced placeholders with real evidence: commit hashes (`8355b9f`, `6c41c8b`, `e0001f9` — all verified to resolve), test names, and a Test status section that no longer says *"implementation not started (spike only)"*. Promotion candidates decided: the lesson was already captured in #337, both ADRs (015, 019) are written, and no vault pattern is warranted since the junction-swap technique has not recurred in another project. ## Scope notes - **`uv.lock` deliberately excluded.** Master's lock has stale `requires-dist` for `mcp` — `pyproject.toml` says `<3.0` since #316, the lock still recorded `<2.0` — so *any* `uv` invocation dirties the tree on a clean checkout. Real (minor) drift, already fixed in **#338**, not duplicated here. - **One `[AGENT-DRAFT]` remains repo-wide**, in `specs/HIVE-118-phase-c-daemon-model/proposal.md:21`. Different spec, out of scope for #333; noted on the issue so it is tracked rather than dropped.
mlorentedev
added a commit
that referenced
this pull request
Aug 9, 2026
…350) ## The drift `AGENTS.md` still described `pyproject.toml` as carrying `mcp>=1.27,<3.0` and concluded the review guard was lost: > **The pin no longer guards what it claims.** `pyproject.toml` now has `mcp>=1.27,<3.0` (widened from `<2.0` by #316). […] this is a lost guard rather than a live bug — but it is a lost guard. That stopped being true when #345 re-narrowed the cap to `<2.0`. #345 fixed the same contradiction inside `pyproject.toml`'s own comment block, so this paragraph was the last place still asserting the widened state — and it sits in the file agents are instructed to read first. ## The correction Rewritten to record *why* the cap is load-bearing rather than only what its value is: - `_compat.py` patches a **private** method, `RequestResponder.respond`. Private internals carry no compatibility promise across a major release, so `<3.0` admitted the whole 2.x line — precisely the boundary the cap exists to exclude. - `apply()` degrading quietly is a real mitigation but the wrong one to lean on: quiet degradation means the cancel-race crash returns with no failing build to announce it. - Notes that `mcp` currently resolves to 1.28.1, comfortably inside the cap. ## Verification Documentation only — one line changed in `AGENTS.md`, no code, no dependency edit. Verified against the tree: `pyproject.toml:49` reads `"mcp>=1.27,<2.0"`. Refs #345, #342, #316. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated compatibility guidance to retain the supported MCP dependency range. * Documented the related issue and current resolved version for easier maintenance. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updates the requirements on mcp to permit the latest version.
Release notes
Sourced from mcp's releases.
... (truncated)
Commits
6f69a37Present v2 as the stable release across the README, docs, and policies (#3178)78e6fbbServe v2 docs at the site root, with permanent per-major paths (#3176)af06330Remove unused StreamableHTTPTransport.get_session_id() (#3205)68ca87eDocument the two-line release process for stable v2 (#3179)c9c431bExpose the middleware chain on MCPServer and stop sending unrequested change ...528e366Fail fast on server-to-client requests in JSON-response mode instead of hangi...27f5cc7Remove unused mcpserver.exceptions.ValidationError (#3199)89c5e70Gate log notifications on the per-request log-level opt-in at 2026-07-28 (#3198)b61ce38docs: fix off-by-one hl_lines in apps.md (#3196)b7c9a91Add mcp.types as a permanent alias for mcp_types (#3190)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)