FastAPI operationId nondeterministic for multi-method routes causing OpenAPI schema hash changes
A FastAPI route registered via @router.api_route(path, methods=["GET", "POST", ...]) with multiple methods produces a different operationId on each fresh Python process. Symptom: an OpenAPI schema hash/fingerprint computed over paths+components changes between otherwise-identical runs, so committed-schema contract checks or generated-SDK diffs (oazapfts etc.) show phantom churn (e.g. ..._head vs ..._options suffixes flipping).
Root cause: FastAPI's default generate_unique_id builds the id as route.name + path + '_' + list(route.methods)[0].lower(), and route.methods is a set — iteration order depends on PYTHONHASHSEED, so list(...)[0] varies across processes. Fixes, best first: (1) if the route is internal (analytics proxy, health plumbing), mark it include_in_schema=False — removes the nondeterminism AND the junk SDK exports (a 7-method catch-all route emits one generated client function per method); (2) pass an explicit operation_id= to the decorator; (3) install a custom generate_unique_id_function on the FastAPI app that sorts methods. Diagnose by generating the schema twice in separate processes and diffing: only multi-method routes will differ.