Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

flatten: one unmergeable property aborts the whole document

Đang mở
  • Có gì không ổn?
#1,261 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
72/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
cli

Hướng nghiên cứu

Start by grepping for all Type values must be identical (and failed to flatten allOf) to find where the flatten aborts, then reproduce with oasdiff flatten conflict.yaml on the snippet in the issue. The goal: keep the unmergeable property as a residual allOf while merging its siblings, so exit 0 and breaking/changelog --flatten-allof succeed. Note PR #1260's enum-gated branch as prior art, decide whether to widen it to any conflict, and update docs/ALLOF.md, which today only documents residual allOf for recursion.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

One property that cannot be merged aborts the flattening of the whole document. Keeping that property as a residual allOf and flattening everything else is exact, and it is what users of --flatten-allof need when a single corner of a large spec is unmergeable.

Raised by @dimitropoulos in #1260, which he later closed on the grounds that the spec that triggered it should be fixed upstream. The spec question is separate from this one: whichever spec caused it, aborting the whole document is a bigger hammer than the situation calls for.

Today

openapi: 3.0.3
info:
  title: type conflict
  version: "1"
paths: {}
components:
  schemas:
    S:
      allOf:
        - type: object
          properties:
            p:
              type: string
        - type: object
          properties:
            p:
              type: integer

$ oasdiff flatten conflict.yaml
Error: failed to flatten allOf in "conflict.yaml": unable to resolve Type conflict: all Type values must be identical

Nothing else in the document is flattened, and breaking/changelog with --flatten-allof fail the same way (exit 122).

What it could do instead

Keep p as allOf: [{type: string}, {type: integer}] and merge the rest. The composition is exact: it accepts and rejects the same payloads as the source, which is the property flatten already promises.

The branch in #1260 demonstrated this, scoped to properties carrying an enum. On a spec with one conflicting property beside a mergeable one, it produced:

"properties": {
  "conflicting": {"allOf": [{"enum": [true], "type": "boolean"}, {"enum": [false], "type": "boolean"}]},
  "flattenable": {"maxLength": 9, "minLength": 2, "type": "string"}
}

So the sibling merged normally while the unmergeable property kept its composition.

Scope question

#1260 gated the fallback on the property having a non-empty enum somewhere in its branches. That makes two identical type conflicts behave differently:

Property Result on that branch
type: string, enum: ["a"] against type: integer residual allOf, exit 0
type: string against type: integer whole document fails, exit 122

The residual composition is exact in both cases, so the enum has no bearing on whether the fallback is sound. If this is implemented, it should cover any unresolvable property conflict.

Also worth deciding

  • Whether the residual composition should be reported, for example as a warning listing the properties that could not be merged, so a user of the flattened output knows where the allOf entries come from.
  • docs/ALLOF.md currently explains residual allOf only around recursion. It would need a second case.
Ngôn ngữ chính
Go
Star
1.4k
Fork
109
Merge trung bình
9 giờ 35 phút
Pull request đã merge (30 ngày)
31

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của oasdiff/oasdiff

Tất cả issue của oasdiff/oasdiff

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.