FastAPI 0.112.0 Duplicate operation_id Warning: Should the framework enforce uniqueness?

FastAPI 0.112.0 automatically generates operation_id values for each path operation using the function name and path. When two routers contain operations that resolve to the same operation_id, FastAPI logs a warning but still includes both entries in the generated OpenAPI schema.

This behavior presents a conflict for client‑generation tools that assume every operation_id is unique. The framework currently offers no mechanism to auto‑rename duplicates or to treat the conflict as a hard error, leaving developers to manually resolve the issue or rely on console warnings that may be suppressed in production.

The unresolved decision is whether FastAPI should:

• automatically generate unique identifiers for duplicate operations, or
• raise a runtime exception to force developers to provide unique operation_id values.

What are the implications of each approach for OpenAPI consumers, SDK generators, and runtime stability?

Specifically:

• Should FastAPI automatically modify duplicate operation_id values to maintain uniqueness while preserving the original intent?
• Would a hard error on duplicate operation_id be preferable to avoid silent schema corruption, and how would this affect backward compatibility?
• What impact would either strategy have on tooling that relies on deterministic operation_id values, such as OpenAPI Generator or Swagger UI?