PRs are added to a stack after creation — early webhooks miss stack, and stacked-PR workflows sometimes don't trigger

[joeljeske]

Summary

A pull request is created first and added to a stack afterward (the stack is
formed from existing PR numbers). For a time window, the PR therefore exists
outside any stack. Two consumer-visible consequences follow from that ordering:

1. The stack object is missing from early PR webhooks (notably
   pull_request.opened), and its presence on later events is nondeterministic.
2. Workflows that should run "as if the PR were on the stack base" are
   sometimes not triggered, especially for PRs in the middle of a stack.

Both trace back to the same root cause: at the moment the PR is created and its
initial events/trigger-evaluations happen, it is not yet part of a stack.

Consequence 1 — webhooks miss stack

Because opened (and other early lifecycle events) fire before the stack is
formed, those payloads carry no stack object. Whether later events for the
same PR include it depends on webhook delivery timing relative to when the stack
was created, so it's not reliable even after the fact:

• The bottom PR (whose base is already the trunk) is unaffected.
• The top/last PR often gets it (its events tend to land after the stack exists).
• Middle PRs frequently never receive an event carrying the stack object at
  all.

A consumer that keys off pull_request.stack therefore sees an inconsistent,
order-dependent view and cannot tell "no stack" from "stacked, but this event
didn't include it."

Additionally, since stack is not accessible from REST / GraphQL APIs, a
diligent consumer cannot supplement the missing data from the server as
its not available. See #139

Consequence 2 — stacked-PR workflows sometimes don't trigger

The documented behavior is that Actions evaluates workflow triggers using the
stack's base branch, so a workflow configured for the trunk
(on: pull_request: branches: [main]) should run for every PR in a stack. In
practice this is not reliably honored for middle PRs: a workflow filtered to
the trunk fires for the bottom PR (its base is the trunk) and for the
last-created PR, but a middle PR — whose immediate base is another stack
branch and which was created/evaluated before the stack existed — does not get
the run, and nothing re-triggers it once the stack is formed.

The impact is more than a missing run: if that workflow is a required check,
the PR is either blocked indefinitely (the required check never reports) or
mergeable with the check silently absent.

Root cause

A PR is observable "on its own," not in a stack, between creation and
add-to-stack. Every consumer that evaluates state at creation time (webhook
deliveries, Actions trigger evaluation, anything reacting to opened) captures
the pre-stack reality, and there is no reliable re-evaluation when the stack is
subsequently formed.

Request

Make stack membership knowable at creation so a PR never exists outside its
stack — ideally by allowing a PR to be added to a stack atomically as part of
creating it (a single operation), so opened and the first trigger evaluation
already reflect the stack.

If atomic creation isn't feasible, the equivalent mitigation is a reliable
membership-change signal when a PR is added to (or removed from) a stack — one
that both delivers the stack object and re-triggers workflow evaluation for the
affected PRs — so consumers and Actions can correct the pre-stack view.

[skarim]

This behavior is expected because PRs are created first and then later added to a stack. In our model, a PR can't be added to a stack until it has first been created.

So the pull_request.opened webhook will never have a stack object in it.

We are working on a new pull_request.stacked webhook that will fire when a PR is added to a stack. (Followed by an unstacked event later on as well.)

The pull_request.stacked event will include a stack object:

"stack": {
  id: 123456,  // global id
  number: 50,  // repo-scoped number (shared numbering across PRs and issues)
  size: 5,     // total number of PRs in stack
  position: 1, // one-based numbering, where 1 is the bottom
  "base": {
    "ref": "main",
    "sha": "def456..."
  }
}