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

Annotate output is not reproducible: properties[] order varies between runs on identical sources

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

@avillar đang làm issue này rồi.

Từ ngày 8/10/2026.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
56/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github-actions, python
Lĩnh vực
build-system

Hướng nghiên cứu

Start by tracing how the postprocess builds and serializes properties[] in the outputs under build/annotated/, especially resolvedProperties.json; the issue provides a concrete example with three sibling entries changing order. Reproduce with identical inputs and check whether iteration over an unordered collection determines the output. Done when repeated runs produce byte-stable ordering for these outputs without changing their contents.

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

Mô tả

Running the postprocess twice over byte-identical sources produces build/annotated/** output that differs only in the order of the properties[] array. The entries are the same; their positions move.

Because this output is committed in our repository, every run looks like a ~1300-file change that contains no change at all, which makes "regenerate and compare" unusable as a check and buries real diffs.

Evidence

Two runs of validate-and-process.yml@v1 (skip-pages: true), producing commits 9496e7c15 and 88eedbaf6 in amds-ldeo/geochemBuildingBlocks. Between those two commits:

  • _sources/ — 0 files changed
  • tapp submodule — unchanged
  • bblocks-config.yaml — unchanged
  • the only non-build/ changes were one GitHub Actions workflow file and a docstring in a tool neither the postprocess nor the schemas read

so the postprocess input was identical. Yet:

  • build/ — 1310 files changed, +166607 −166607 (symmetric)
  • 40 of 40 sampled JSON outputs are order-insensitively identical (comparison canonicalising both dict key order and list element order); 0 genuinely different
  • affected output kinds: resolvedProperties.json (131), index.json (198), _report.json (242), schema-oas3.0.json / .yaml

Minimal example

build/annotated/BaseSchema/tappDefinition/resolvedProperties.json — 215 properties[] entries in both runs, identical multiset, 3 positions differing, a clean rotation:

 [123]  A: schema:actionProcess.schema:step.schema:additionalProperty.schema:unitText
        B: schema:actionProcess.schema:step.schema:additionalProperty.schema:name
 [124]  A: schema:actionProcess.schema:step.schema:additionalProperty.schema:name
        B: schema:actionProcess.schema:step.schema:additionalProperty.schema:propertyID
 [125]  A: schema:actionProcess.schema:step.schema:additionalProperty.schema:propertyID
        B: schema:actionProcess.schema:step.schema:additionalProperty.schema:unitText

Three sibling properties of one object, emitted in a different order each run. That pattern — a small group of siblings rotating — is what an unordered collection (a set, or a dict built in traversal order and iterated without sorting) looks like when it reaches the output.

Suggested fix

Sort properties[] before serialising — by path (and id as a tiebreak) would be stable and also easier to read. More generally, any collection that reaches committed output needs a defined order.

We hit the same class of bug in our own generators and fixed it the same way; we also added a CI check that regenerates under two different PYTHONHASHSEED values and compares, which catches exactly this. If the ordering here derives from set/dict iteration, that check would likely reproduce it in your CI cheaply.

Why it matters downstream

build/annotated/** is committed in our repository because our Pages deploy reads it without regenerating. With non-deterministic ordering:

  • a "regenerate and diff" check cannot distinguish a real change from reordering
  • every source change produces a large spurious diff, so genuine changes are not reviewable
  • the postprocess reports success, so nothing signals that the output is unstable

Happy to supply fuller diffs, the comparison script, or run an instrumented build if that helps isolate it.

Environment

  • opengeospatial/bblocks-postprocess/.github/workflows/validate-and-process.yml@v1, default image_tag
  • observed 2026-10-07
Ngôn ngữ chính
Python
Star
1
Fork
6
Merge trung bình
1 ngày
Pull request đã merge (30 ngày)
6

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

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

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 opengeospatial/bblocks-postprocess

Tất cả issue của opengeospatial/bblocks-postprocess

Issue tương tự

Thêm issue về Python

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.