Three small things found while moving the endpoint documentation out of resources/openapi.yml and into the route decorators. None is urgent; grouping them rather than filing three issues.
1. apidocs.py:41 calls a dict.construct_open_api_schema() starts with:
ifapp.openapi_schema:
returnapp.openapi_schema()
app.openapi_schema is a dict, so this would raise TypeError: 'dict' object is not callable. It is unreachable today only because server.py assigns app.openapi_schema = construct_open_api_schema(app) directly rather than going through app.openapi(). Should be return app.openapi_schema.
2. Duplicate function names.get_setid is defined twice (server.py:327 and :348) and get_curie_prefixes_handler is defined twice (:394 and :407). The routes register correctly because FastAPI keys off the decorator, but the module-level name only binds to the second definition, and FastAPI derives operationId from the function name — so the generated operation IDs collide, which some client generators reject.
3. Declared OpenAPI version is ignored.resources/openapi.yml starts with openapi: 3.0.2, but that key is never copied into the served schema, and FastAPI 0.108 emits 3.1.0. If SmartAPI or Translator registration expects 3.0.x, this is the reason. Worth either deleting the misleading key or actually pinning the emitted version.
Three small things found while moving the endpoint documentation out of
resources/openapi.ymland into the route decorators. None is urgent; grouping them rather than filing three issues.1.
apidocs.py:41calls a dict.construct_open_api_schema()starts with:app.openapi_schemais a dict, so this would raiseTypeError: 'dict' object is not callable. It is unreachable today only becauseserver.pyassignsapp.openapi_schema = construct_open_api_schema(app)directly rather than going throughapp.openapi(). Should bereturn app.openapi_schema.2. Duplicate function names.
get_setidis defined twice (server.py:327and:348) andget_curie_prefixes_handleris defined twice (:394and:407). The routes register correctly because FastAPI keys off the decorator, but the module-level name only binds to the second definition, and FastAPI derivesoperationIdfrom the function name — so the generated operation IDs collide, which some client generators reject.3. Declared OpenAPI version is ignored.
resources/openapi.ymlstarts withopenapi: 3.0.2, but that key is never copied into the served schema, and FastAPI 0.108 emits3.1.0. If SmartAPI or Translator registration expects 3.0.x, this is the reason. Worth either deleting the misleading key or actually pinning the emitted version.