Degenerate boolean schemas misreport at every schema-slot existence check, not only media types

Offen
  • Stimmt etwas nicht?
#1,199 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
57/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
go
Bereich
api

Rechercherichtung

Start from classifyOneSidedSchema in check_media_type_schema_existence.go, then run the oasdiff checks changelog coverage -f json jq filter quoted in the issue to enumerate the ~40 covered schema-slot cells. For each cell, find its existence check and reproduce the probe (a property or conjunct whose schema is false or true) with oasdiff changelog to see today's verdict before changing anything. Done when degenerate schemas no longer yield false verdicts, generalizing the annotation-only routing the allOf branch checks already use; the remaining id-routing decision for the false case tracks issue #1196.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

MediaTypeSchemaExistenceCheck classifies a body schema that appears or disappears by what the schema is: false routes to the schema-became-false ids and a schema equivalent to the empty schema reports nothing. Every other check that reports a schema-valued slot appearing or disappearing still classifies by the edit's shape alone, and the same two degenerate schemas misreport there.

Confirmed probe, on main:

# revision adds an optional property whose schema is the boolean false
properties:
  name: {type: string}
  legacy: false

$ oasdiff changelog base.yaml revision.yaml
info [new-optional-request-property] added the new optional request property `legacy`

A key that every request was previously free to send is now invalid whenever present: a request narrowing reported as a safe addition. (Under additionalProperties: false the key was already rejected, so the honest verdict may need that sibling, the same nuance as request-property-removed.)

The triage list is mechanical

The candidate sites are exactly the covered coverage cells whose location ends in a schema-valued slot with a set/unset/add/remove action:

$ oasdiff checks changelog coverage -f json | jq -r '.[] | select(.status=="covered")
    | select(.action | IN("set","unset","add","remove"))
    | select(.location | test("\\.(schema|items|itemSchema|not|if|then|else|contains|propertyNames|properties\\.\\*|prefixItems\\.\\*|oneOf\\.\\*|anyOf\\.\\*|allOf\\.\\*)$"))
    | [.location, .action, (.checks | join(","))] | @tsv'

That yields roughly forty cells: the properties existence checks (request, response, parameter header properties), the subschema branch checks (allOf/anyOf/oneOf added and removed), the 3.1 applicators (if/then/else, contains, propertyNames), and the itemSchema pair already tracked in #1196. Waived cells need nothing: no check fires, so there is no verdict to get wrong.

Expected failure modes per cell

  • Response-side false arrivals are the ones that matter: a safe verdict on a change that makes something unproducible (the probe above is the request-side sibling; response-body-all-of-added with a false conjunct is the response-side one, info today).
  • Request-side false arrivals usually land on the right level for the wrong reason, with a message describing a constraint rather than an impossibility.
  • true / empty-equivalent arrivals and departures are contract no-ops reported as changes; on request-narrowing cells that is a false breaking verdict. The allOf branch checks already handle this via their annotation-only routing, which is the pattern to generalize.

classifyOneSidedSchema (check_media_type_schema_existence.go) is the reusable classifier; the open per-cell question is the same one as #1196: which id the false case routes to.

Vorherrschende Sprache
Go
Sterne
1.4k
Forks
109
Ø Merge
1 T. 17 Std.
Gemergte PRs (30 T.)
56

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

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

Mehr aus oasdiff/oasdiff

Alle Issues in oasdiff/oasdiff

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.