Reordering history can accidentally "merge" an intermediate PR in `--direct` mode

Haven't put a lot of time into understanding this one, was just trying to evaluate ghstack for work on LLVM. The issue was that while editing and reordering commits, one of their PRs was automatically marked "Merged", when I had not merged anything. I assume this is due to the lack of an atomic way to update base branches for several PRs at once, but unsure the exact cause.

Simplest way to reproduce turned out to be to just swap the position of two commits in a stack repeatedly:

#!/bin/bash

stack() {
  ghstack --direct || return 1
  # attempt to rule out racing against a slow GH or something, doesn't seem to
  # matter, and I hit the bug originally while just using the tool by-hand
  #sleep 10
}

swap2() {
  # swap the 2nd and 3rd `pick` lines in the interactive rebase buffer
  GIT_EDITOR='printf "%s\n" 2y 2d x w | ed -s' git rebase -i origin/main
}

init() {
  for n in $(seq 4); do
    echo $n >> $n && git add -A && git commit -m $n || return 1
  done
}

whirl() {
  # seems to pretty regularly break on round 3, but add plenty to be sure.
  # not actually clear to me if this is deterministic or not
  for n in $(seq 10); do
    stack && swap2 || {
      printf 'failed on round %d\n' $n
      return 1
    }
  done
}

main() {
  init && whirl
}

"$@"

Can run as foo.sh main to have it build a short stack and then start swapping and restacking until it breaks.

If there is more info I can share, let me know. I only spent enough time to be sure I wasn't just holding it wrong.

Reproduce the failure with the supplied foo.sh script, using ghstack --direct and repeated interactive reordering against origin/main. Trace the stack update and GitHub PR status changes involved in the reordering; done means swapping the second and third commits repeatedly no longer marks an intermediate PR as merged.