checker: pattern_added_or_changed has no body-level rules
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
这个 Issue 还没有评估数据。
描述
Surfaced while reviewing the walker migration in #949.
What's missing
check_request_property_pattern_added_or_changed.go and check_response_pattern_added_or_changed.go only emit property-level changes:
request-property-pattern-removedrequest-property-pattern-addedrequest-property-pattern-changedrequest-property-pattern-generalized
(and the response equivalents)
There are no body-level counterparts (request-body-pattern-* / response-body-pattern-*) — the constants don't exist, and the checker never inspects mediaTypeDiff.SchemaDiff.PatternDiff at the body level.
When this matters
OpenAPI lets the top-level request or response body be a string-typed schema with a pattern field, e.g.:
requestBody:
content:
text/plain:
schema:
type: string
pattern: "^[a-z]+$"
If the pattern changes (^[a-z]+$ → ^[A-Z]+$), that's a breaking change for clients sending payloads matching the old pattern. Today's checker doesn't notice — oasdiff breaking returns clean for that change.
How common is it
Probably rare. Top-level string-typed bodies are unusual in REST APIs; the common case is the body schema has properties, which the property-level checker handles correctly. But the gap is real and an asymmetry vs every other body+property pair (anyOf / oneOf / allOf / nullable / type / min / max / dependent_schemas / prefix_items / etc all check both levels).
Fix shape
Mirrors the body-level pairs in the other recently-migrated checkers. Concretely:
- Add four constants in each file (
RequestBodyPatternRemovedIdetc). - In the walker callback, emit at body level when
info.schemaDiff.PatternDiff != nil, following the same four-case split (removed / added / changed / generalized) the property branch already does. - Add localized messages in
checker/localizations_src/for all four locales (en, es, pt-br, ru). - Tests using a top-level string body fixture.
Estimated: ~80 lines per side plus a couple of test fixtures. Probably half a day end-to-end with localisation.
Low priority — anyone who has top-level string-typed bodies in their spec, please add a 👍.
- 主要语言
- Go
- 星标
- 1.4k
- 派生
- 109
- 平均合并
- 11 小时 5 分钟
- 30 天内合并 PR
- 32
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
oasdiff/oasdiff 的其他 Issue
-
`date` → `date-time` (and `time` → `date-time`) is classified as a widening, but a date is not a valid date-time可能已有人在做 @reuvenharrison 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
难度 3/5 半天 新手友好度 68/100
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 75/100
维护者通常 1 天内回复
-
A required response property becoming `writeOnly` is reported at info, though it is no longer returned可能已有人在做 @reuvenharrison 今天认领。 未关闭
难度 3/5 半天 新手友好度 72/100
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 72/100
维护者通常 1 天内回复
相似的 Issue
-
kind/bug
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 4 天内回复
-
bug needs-acceptance
难度 2/5 1-3 小时 新手友好度 86/100
vllm-project/semantic-router#4744 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
jaegertracing/jaeger#9794 ·
维护者通常 1 天内回复
-
ScalingModifiers formula fails with "formula returned non-float result" when expression evaluates to an integer可能已有人在做 @Sarthak-Pandey 今天认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 73/100
维护者通常 1 天内回复