Kunal8954 commented on code in PR #72470:
URL: https://github.com/apache/airflow/pull/72470#discussion_r3925418985
##########
airflow-core/src/airflow/api_fastapi/common/headers.py:
##########
@@ -27,10 +27,18 @@ def header_accept_json_or_text_depends(
accept: Annotated[
str,
Header(
+ description="The response content type to negotiate for.",
+ # Listed as "examples", not "enum": a real Accept header isn't
restricted to
+ # these exact literals (it may carry q-values, be comma-separated,
etc.), and
+ # an "enum" containing the literal "*/*" gets rendered by some
OpenAPI client
+ # generators (notably the Java generator) as a named enum constant
whose
+ # generated Javadoc embeds that raw value - the "*/" inside it
prematurely
+ # closes the Javadoc comment block and breaks the generated client.
+ # See https://github.com/apache/airflow/issues/72466
json_schema_extra={
"type": "string",
- "enum": [Mimetype.JSON, Mimetype.TEXT, Mimetype.ANY],
- }
+ "examples": [Mimetype.JSON, Mimetype.TEXT, Mimetype.ANY],
Review Comment:
Good question - this turned up something important, so thanks for pushing on
it.
I generated *and compiled* the Java client against the regenerated spec
(via the openapitools/openapi-generator-cli Docker image + a Maven
compile, not just the generation step). Compilation still fails, both
before and after this PR's enum->examples change.
The break isn't the enum constant I originally suspected - it's this
line in the generated Javadoc:
* @param accept (optional, default to */*)
That "default to */*" text comes straight from the header's `default`
value (which is correct and shouldn't change), and openapi-generator's
Java template embeds it raw with no comment-safe escaping - completely
independent of whether the schema says `enum` or `examples`. You can
confirm the default itself is unaffected: `default: '*/*'` is still
present in the regenerated spec.
I've filed the actual root cause upstream:
OpenAPITools/openapi-generator#<TBD>
So to directly answer your question: yes, tested with generator 7.25.0
(this repo's own pinned version) and it still doesn't compile - this PR
alone doesn't close that gap. I've updated the PR description to reflect
that honestly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
