Add additionalProperties to ErrorCause and fix creation_date type for list_dangling_indices #462
Conversation
Changes AnalysisCommit SHA: 6ac6529 API ChangesSummary
ReportThe full API changes report is available at: https://github.com/opensearch-project/opensearch-api-specification/actions/runs/10242927832/artifacts/1774856934 API Coverage
|
08b0477 to
e94e248
Compare
Spec Test Coverage Analysis
|
e94e248 to
6bffec2
Compare
| @@ -53,7 +53,7 @@ export function determine_possible_schema_types (doc: OpenAPIV3.Document, schema | |||
| if (schema?.anyOf !== undefined) return collect_all(schema.anyOf) | |||
| if (schema?.oneOf !== undefined) return collect_all(schema.oneOf) | |||
|
|
|||
| if (schema == null || Object.keys(schema).filter(k => k !== 'description').length == 0) return SCHEMA_OBJECT_TYPES | |||
| if (schema == null || Object.keys(schema).filter(k => k !== 'description' && k !== 'title').length == 0) return SCHEMA_OBJECT_TYPES | |||
There was a problem hiding this comment.
Could you please explain this change?
There was a problem hiding this comment.
If nothing is specified in the schema other than "informational" properties (ie. description or title) than it can be any type.
6bffec2 to
13778fb
Compare
… list_dangling_indices Signed-off-by: Thomas Farr <tsfarr@amazon.com>
13778fb to
6ac6529
Compare
| creation_date: | ||
| $ref: '_common.yaml#/components/schemas/DateTime' |
There was a problem hiding this comment.
I'm thinking we might want some way of annotating properties as being the human readable variant of another property and dependent on ?human. Would be useful for documentation or want to do some custom logic in clients/generators.
Maybe something like:
creation_date:
x-human-readable-of: creation_date_millis
There was a problem hiding this comment.
It does feel a little too special, applying only to the _cat API. Are there exceptions where something like x always have a pair of x_millis and lives only under _cat?
There was a problem hiding this comment.
Well it's not only the _cat api as this particular one is in the dangling_indices api and not only applies to _millis variants, also bytes ones
There was a problem hiding this comment.
Would it be over-engineering to hide it under a type?
total:
type: ...HumanlyReadableByteSize
description: Total number of bytes.
would get automatically expanded as total and total_in_bytes when spec gets generated?
I'm just thinking out loud. The drawback of x-human-readable-of is that it's a relationship that needs to be validated. If you think it's the cleanest way to do it, go for it - and maybe @nhtruong has some other ideas?
Description
Add additionalProperties to ErrorCause and fix creation_date type for list_dangling_indices
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.