Child PRs not automatically re-evaluated when parent PR merges

[astubbs]

Summary

When a parent PR (the dependency) merges, the child PR (the one with depends on #X in its description) is not automatically re-evaluated. The child's status check remains failed until someone manually intervenes.

This seems like the most critical missing feature — the whole point of declaring dependencies is that the child should automatically become unblocked when the parent merges.

Reproduction

1. Create Parent PR #A
2. Create Child PR #B with depends on #A in the description
3. Child PR #B correctly shows a failing status check ✅
4. Merge Parent PR #A
5. Expected: Child PR #B's status check automatically re-runs and passes
6. Actual: Child PR #B remains stuck with the failed check. It only clears if someone:
   • Manually clicks "Re-run failed jobs"
   • Pushes a new commit to the child PR
   • Edits/closes/reopens the child PR

Root cause

The workflow trigger only listens for events on the child PR itself:

on:
  pull_request_target: 
    types: [opened, edited, closed, reopened]

There is no mechanism to detect that a parent PR has merged and then re-evaluate all child PRs that reference it.

Possible solution

Add a companion trigger on pull_request_target: [closed] that, when a PR merges:

1. Searches for open PRs whose body contains a reference to the just-merged PR (e.g., depends on #X)
2. Re-triggers the dependency check on those child PRs (e.g., via workflow_dispatch or by re-running their check)

This would make the dependency lifecycle fully automatic — children block while the parent is open, and unblock when it merges — without any manual intervention.

Context

I'm evaluating this action for managing stacked PR chains in my fork of parallel-consumer. This is the one thing preventing me from adopting it. Happy to contribute a fix via PR if you're open to it.

Great action by the way — clean, simple, and solves a real gap in GitHub's tooling. 👍

[gregsdennis]

This is a known limitation. I just rerun it manually.

(1) in your solution could only work on the same repo.

Lastly, GitHub is actually releasing this as a feature soon.