Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,199 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
57/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
go
Área
api

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
1.4k
Forks
109
Merge medio
9 h 35 min
PR fusionados (30 d)
31

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de oasdiff/oasdiff

Todos los issues de oasdiff/oasdiff

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.