Summary

Some middleware lazily calls http_server.initialize() on first protected request without a concurrency guard. Under load, multiple simultaneous requests can race, triggering multiple inits and inconsistent error propagation.

Scope

• Audit all middleware (not just FastAPI) that lazily initializes facilitator support on-demand.
• Ensure async and sync variants are safe under concurrent requests/threads.

Affected areas to review

• Python FastAPI middleware (x402.http.middleware.fastapi)
• Python Flask middleware (x402.http.middleware.flask)
• Any other frameworks/languages that use init-on-first-protected-request patterns

Desired outcome

• Single-flight initialization (async: asyncio.Lock or shared init task; sync: threading.Lock or equivalent)
• Centralized error propagation if init fails
• Tests or documentation to cover expected behavior under concurrent requests