Skip to content

merge queue: checking main (dee3261) and #1780 together - #1783

Closed
mergify[bot] wants to merge 2 commits into
mainfrom
mergify/merge-queue/9e75896c6f
Closed

merge queue: checking main (dee3261) and #1780 together#1783
mergify[bot] wants to merge 2 commits into
mainfrom
mergify/merge-queue/9e75896c6f

Conversation

@mergify

@mergify mergify Bot commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

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

Branch main (dee3261) and #1780 are queued together for merge.

This pull request has been created by Mergify to check the mergeability of #1780.
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: dee3261a05101b7d80642ca7376d65b92659a376
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 1780
    scopes: []
scopes: []
...

jd and others added 2 commits August 21, 2026 22:06
With `--github-native`, `mergify stack push` registers the stack with
GitHub's Stacks API, and that registration *is* the dependency between
two pull requests. The `Depends-On: #<n>` header the CLI writes on top
of it records the same edge a second time, in the copy users actually
read — so it is now left out.

Keyed off the registration, never off the flag. `--github-native`
degrades silently by design: `native_stack::register` returns `None` on
a 404 (old GHES, feature off for the repo), a chain with a hole in it,
or a stack below GitHub's 2-PR floor, and the push carries on as an
ordinary Mergify stack. Dropping the header on the flag alone would
leave those pushes with the edge recorded nowhere at all, and Mergify
reconstructs a stack from `Depends-On` chains
(`engine/stacks/detection.py`) — a mid-stack pull request would lose
the gate holding it behind its predecessor.

Registration happens after the bodies are written, so the removal is
optimistic and settled inside the same push: every header the upsert
skips is remembered, and `pr_upsert::restore_depends_on` writes it back
(body only, no `base` key) if the stack ends the push unregistered.
That path is fatal on failure — every other way this feature degrades
lands in the state a flag-off push produces, and a stack that is
neither registered nor chained would not.

Nothing writes `Depends-On` into a commit; it only ever existed in the
rendered PR description, so no commit message changes shape.

What still reads the header, checked against the engine rather than
assumed:

- `stacks/detection.py` walks CLI stacks by branch chain **and** the
  marker; its native counterpart `stacks/github_native.py` walks the
  mirrored `stack` object instead, and `get_stack_predecessor_state`
  unions the two. The native half is behind
  `GITHUB_STACK_QUEUE_FOR_ORGS`, but an org without that flag cannot
  merge a registered stack at all — `merge_helpers` keeps it off the
  merge-async path and GitHub 403s the classic endpoint for every
  member — so the marker there gates a merge that cannot happen.
- The queue's `build_stack_groups` and
  `find_direct_open_successors_by_head_ref` use head/base refs only.
- The browser extension reads its own `mergify-stack-data` comment.
- The stacks-analytics endpoint detects stack PRs by `Change-Id` (which
  we still write); only its bottom-vs-upper first-review split reads
  the marker, so native stacks will read as all-bottom there. Metrics
  skew on an opt-in flag, not a merge regression — worth its own fix.

MRGFY-8772

Change-Id: Ia15a76dec74d7799bf891ab5c0d14211aba2bb9e
@mergify
mergify Bot deployed to Mergify Merge Protections August 24, 2026 11:52 Active
@mergify
mergify Bot deployed to func-tests-live August 24, 2026 11:52 Active
@mergify mergify Bot closed this Aug 24, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/9e75896c6f branch August 24, 2026 11:59
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