@jlowin this draft is still pointing to a branch of docket where I'm validating that we won't have any compatibility problems with 2.x when I release it. Will bump the version here once I'm sure.

Test Failure Analysis

(Updated 2026-02-26 — edited to reflect latest workflow run 22445358624)

Summary: Two integration tests in TestGithubMCPRemote timed out (>30s) while waiting for a response from the GitHub Copilot remote MCP server (https://api.githubcopilot.com/mcp/). This is unrelated to the code changes in this PR.

Root Cause: The failures are transient network timeouts against an external third-party service. Both test_list_tools and test_call_tool_list_commits made real HTTP connections to https://api.githubcopilot.com/mcp/ and received no response within 30 seconds. The asyncio event loop was blocking on epoll_wait awaiting data that never arrived from the remote GitHub MCP server.

Suggested Solution: Re-run the failed integration test job. These failures are caused by external service unavailability, not by code changes in this PR. No code modifications are needed.

Failed: Timeout (>30.0s) from pytest-timeout

DEBUG    [Client-c605] called call_tool: list_commits    tools.py:133

selectors.EpollSelector.select(timeout=29.745)
  fd_event_list = self._selector.poll(timeout, max_ev)
E  Failed: Timeout (>30.0s) from pytest-timeout.

Test Failure Analysis

(Updated 2026-03-02 — edited to reflect latest workflow run 22596255403)

Summary: The integration test test_github_api_schema_performance timed out (>10s) during list_tools() due to slow schema dereferencing. This failure appears unrelated to the PR's DI library changes.

Root Cause: The timeout occurred inside _merge_ref_siblings in src/fastmcp/utilities/json_schema.py, which is called recursively during dereference_refs for each of the 500+ tools in the GitHub API schema. This function runs synchronously for every tool in list_tools() via DereferenceRefsMiddleware. The test fetches a live schema from github/rest-api-description main branch — if that schema has grown or if the CI runner was under load, the 10s timeout can be breached. The PR's changes (swapping _vendor/docket_di for uncalled-for) do not touch the schema dereferencing path.

Suggested Solution: Re-run the failed integration test job — this looks like a flaky failure due to CI environment performance variability and/or the live-fetched GitHub schema having grown. If it consistently fails after re-runs, the schema should be pinned to a specific commit/tag rather than fetching from main.

FAILED tests/server/providers/openapi/test_openapi_performance.py::TestOpenAPIPerformance::test_github_api_schema_performance
- Failed: Timeout (>10.0s) from pytest-timeout.

tests/server/providers/openapi/test_openapi_performance.py:65: in test_github_api_schema_performance
    tools = await mcp_server.list_tools()
src/fastmcp/server/middleware/dereference.py:30: in on_list_tools
    return [_dereference_tool(tool) for tool in tools]
src/fastmcp/server/middleware/dereference.py:52: in _dereference_tool
    updates["output_schema"] = dereference_refs(tool.output_schema)
src/fastmcp/utilities/json_schema.py:101: in dereference_refs
    merged = _merge_ref_siblings(schema, dereferenced, defs)
src/fastmcp/utilities/json_schema.py:169: in _merge_ref_siblings  [repeated many times]
    result[key] = _merge_ref_siblings(original[key], value, defs, visited)

I believe this also closes #3251

I think it could! We can do a little more here to support Shared in the case where you don't have tasks enabled, let me take a look at that, it should be a fairly quick add.

@omikader thanks for the nudge, this was definitely straightforward to ensure: 80526ba

I took off the breaking change label because I disagree with that assessment, I've gone to a lot of trouble in Docket to make sure it's still presenting the same import surface and behavior as it did in 0.17.x