Validation of required fields inconsistent

Offen

#373 erstellt am 09.8.2024 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 5/5
Geschätzter Aufwand: Über eine Woche
Anfängerfreundlichkeit: 25/100

Issue-Typ: Bug
Klarheit: Muss geklärt werden
Aktivitätsstatus: Veraltet
Tech-Stack: python
Bereich: api, testing-qa

Rechercherichtung

The issue names no files or tests. First read the linked discussions and referenced issues #154, #312, #97, and #266 to determine the intended required-field validation policy, then locate the corresponding validator and tests. Done means the project has a decided, consistent behavior for standard, allOf, and referenced schemas, with coverage for that behavior.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

kind/bug/confirmed

The validation of the required keyword does not make sense as it is implemented right now, IMHO.

It really does not make any sense to list properties in required that do not exist.
If you want to use it with allOf and therefore have properties in required that do not exist, there are already precautions (#154).
Currently, there is no validation error in the standard case but as soon as I have allOf in my schema, there is a validation error. That is inconsistent. The PR that breaks it: #312
In $referenced schemas, the validation does not take effect either.

One of the main reasons why this should urgently be validated (as was in version 0.7.0) is that validators (that use the specification to validate requests/responses) will fail if there is e.g. a typo in one of the entries in required. And now there is no way to detect that.

In general, the OpenAPI/JsonSchema specification is quite relaxed. If only the bare minimum should be validated, this is probably not the only validation that can basically be removed completely.

My take on this:

Best case: Throw validation errors for things that are obvious errors (like specifying a field as required that does not even exist).
Second best option: make it configurable ("strict mode") or filterable (error IDs to exclude, filter levels, ...).
Absolutely necessary minium: make it consistent.

I'd be willing to provide a PR. But since this has been going back and forth I'd like a decision first, where this is going.

Vorherrschende Sprache: Python
Sterne: 409
Forks: 73
PR-Merge-Kennzahlen: Keine gemergten PRs in 30 T.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus python-openapi/openapi-spec-validator

Unbounded cache in SpecValidator.iter_errors retains validator instances and schemas Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 55/100

python-openapi/openapi-spec-validator#523 · Erstellt am 08.9.2026
Bug: internal library exception is leaked Offen

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 55/100

python-openapi/openapi-spec-validator#511 · Erstellt am 09.6.2026
version 0.7.2 is not compatible with open api version 0.19.4 Offen

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 30/100

python-openapi/openapi-spec-validator#401 · Erstellt am 10.6.2025
Possible Regression: RecursionError validating oneOf/allOf schema in 0.7.2 (works in 0.7.1) Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 42/100

python-openapi/openapi-spec-validator#400 · 1 Kommentar · Erstellt am 10.6.2025
Need of recursive properties check in validation Offen

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100

python-openapi/openapi-spec-validator#372 · Erstellt am 08.8.2024

Alle Issues in python-openapi/openapi-spec-validator