Skip to content

merge queue: checking main (a24b731) and #12293 together - #12329

Closed
mergify[bot] wants to merge 2 commits into
mainfrom
mergify/merge-queue/859cb47585
Closed

merge queue: checking main (a24b731) and #12293 together#12329
mergify[bot] wants to merge 2 commits into
mainfrom
mergify/merge-queue/859cb47585

Conversation

@mergify

@mergify mergify Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

🎉 This pull request has been checked successfully and will be merged soon. 🎉

Branch main (a24b731) and #12293 are queued together for merge.

This pull request has been created by Mergify to check the mergeability of #12293.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.

Required conditions of queue rule default for merge:

Required conditions to stay in the queue:

---
checking_base_sha: a24b731bcc7b1c18bb9f00b789c6efce9c4d9d7b
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 12293
    scopes: []
scopes: []
...

kozlek and others added 2 commits August 6, 2026 09:51
The engine is changing how it publishes per-value documentation for a
schema's choice set, moving from an `x-enum-descriptions` map to a
positional `x-mergify-enum` array that also carries a display title and a
deprecation flag. Schema syncs land as direct pushes to main, so the docs
repo cannot assume both sides move together.

Introduce `readEnumChoices`, which tolerates every shape a synced schema
can be in during that migration: values as a flat `enum`, a `const`, or
the `anyOf` of branches a composed `Literal` produces, with the node — or
any single branch of it — either inline or behind a `$ref`. Hoisting
repeated enums into shared components is what removes the duplicated
blocks from the published schema, and a reader that followed only the
property node would silently render an empty table once that happens.

Three things the shape change makes possible that the map could not, and
which are handled explicitly because each fails silently:

- Metadata can sit on the referring node as a `$ref` sibling rather than
  on the target, which is how pydantic publishes an annotation for a
  hoisted type. Both are consulted, nearest first.
- A positional array can fall out of alignment with `enum` in a way a
  keyed map never could. A length mismatch is treated as unusable rather
  than shifting every description onto the wrong value.
- The two shapes can coexist on one node mid-migration, so they are
  merged rather than treated as alternatives.

Ref resolution uses the `jsonpointer` the sibling readers already use:
hand-decoding each segment raises `URIError` on a pointer containing a
stray `%`, which would break the never-throws contract this reader
depends on to degrade instead of failing the build.

The dequeue reason table moves onto it here; the batch status table is
written against it from the start in a later commit. Rendered output is
unchanged.

Part of MRGFY-8330

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Change-Id: Ie539de06bf3391eb4390333810cda6e8f131b1e6
@mergify
mergify Bot deployed to Mergify Merge Protections August 6, 2026 08:09 Active
@mergify mergify Bot closed this Aug 6, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/859cb47585 branch August 6, 2026 08:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant