OpenAPI 3.1 update (doc, anyOf remove). Logger, DemoAdapter upd#40
OpenAPI 3.1 update (doc, anyOf remove). Logger, DemoAdapter upd#40gabor-lbl merged 2 commits intodoe-iri:mainfrom
Conversation
juztas
commented
Feb 23, 2026
juztas
commented
- Avoid anyOf where possible;
- Add logger and print all log files; Allow control logger level;
- Demo adapter: add CommandError for subprocess run. run subprocess with check=True, raise error if fails;
- Add descriptions to all models, get rid of str | None - this produces anyOf. Make spec compliant with Johns code.
- Facility worker (skip None values). If field str, cant assign None.
- Remove pyhums (no need capitalize, decapitalize)
- Avoid anyOf where possible; - Add logger and print all log files; Allow control logger level; - Demo adapter: add CommandError for subprocess run. run subprocess with check=True, raise error if fails; - Add descriptions to all models, get rid of str | None - this produces anyOf. Make spec compliant with Johns code. - Facility worker (skip None values). If field str, cant assign None. - Remove pyhums (no need capitalize, decapitalize)
| gpu_cores_per_process: Annotated[int | None, Field(ge=1, description="Number of GPU cores to allocate per process")] = None | ||
| exclusive_node_use: Annotated[StrictBool, Field(description="Whether to request exclusive use of allocated nodes")] = True | ||
| memory: Annotated[int | None, Field(ge=1, description="Amount of memory to allocate in bytes")] = None | ||
| node_count: Annotated[int, Field(ge=1, description="Number of compute nodes to allocate", example=2)] = None |
There was a problem hiding this comment.
Annotated vs Field - what's the rule for which one to use?
There was a problem hiding this comment.
Based on recommendations:
Use of Annotated[T, Field(...)] for constraints & metadata.
Use of int | None (or Optional[T]) only to express that the field can be null.
int | None or Optional[T] translates in OpenAPI anyOf: [integer, null]. That is not a bug. That’s the schema saying “this can be null.” And this is one of the things we want to avoid: for automated tooling and Java compliance. Field (without None or Optional) is legacy, but all automation tools/Java are not yet up to speed with 3.1
| description="If set to `true` creates all its parent directories if they do not already exist", | ||
| ) | ||
| """Represents a request to create a directory.""" | ||
| parent: bool = Field(default=False, description="If set to `true` creates all its parent directories if they do not already exist", example=True) |
There was a problem hiding this comment.
Can Field(default=False) be excluded from the call, like Optional[bool]?
There was a problem hiding this comment.
I think this should be strictly False or True, and not nullable. Making it optional (or None) - introduces a third state to "turn on the light bulb". Yes, No (or Maybe). That is confusing.
2 participants
