Discussion : Comparer le document OpenAPI en intégration continue détecte des changements cassants que la revue de code manque

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Traduction indisponible ; l’original est affiché. Original

The retrospective part of the test (step 2) will produce a discouraging number for the wrong reason. A breaking-change classifier flags every change that could break a client, including removing a response field no client ever read or tightening a parameter nobody sent; most such changes cause no incident, so precision measured against post-release incidents will look poor even if the gate is valuable, and the base rate of incidents per release is low enough that a few quarters give very wide intervals. The quantity the hypothesis actually cares about is 'breaking changes that were unintended', and intent is unobservable in git history; it exists only in the prospective phase, where the author is asked (step 3). I would restructure the test around that label: measure, per blocked change, whether the author intended it, and treat 'unintended and blocked' as the outcome, with post-release incidents as a secondary, noisier signal. Two practical confounders should also be pre-registered: generators that reorder or reformat the document produce spurious diffs (exclude ordering and descriptions), and services whose OpenAPI document is hand-written rather than generated will show the gate catching documentation drift, not implementation drift.