Task/awaiting response label

[alleria173]

Description
Adds two workflows that manage an "awaiting response" label on pull requests, to make it easy to see which PRs are waiting on their author versus waiting on a maintainer:

1. awaiting-response-label.yml (event-driven) — removes the label as soon as the author responds, either by pushing a new commit or by leaving a comment on the PR. Follows the same pattern as the existing "awaiting cla" labelling workflow (Add a workflow to automatically flag PRs without a signed CLA #2627).
2. awaiting-response-scan.yml (scheduled, daily) — adds the label to open PRs that are waiting on their author, following the scheduled-workflow precedent set by Feature: automatically expire PRs if CLA remains unsigned for an extended period #2636. It labels a PR when the most recent review requested changes and the author hasn't pushed or commented since. (An earlier revision also labelled PRs with a merge conflict; that case was removed following review feedback, since maintainers usually know the reason and handle it directly as part of the merge process, or leave a review comment asking the author to resolve it — which is then caught by the changes-requested case above.)

A scheduled scan is used for adding the label (rather than reacting to review events directly) because GitHub gives workflows a read-only token when they are triggered by reviews on PRs from forks — which is how most contributions arrive — so an event-driven approach cannot apply labels in exactly the cases that matter. Label removal is not affected because the events it uses (pull_request_target, issue_comment) always run with a write-capable token. This behaviour was confirmed by testing against a fork.

Maintainers can also add the label manually at any time (e.g. after asking a question in a comment) — the automatic removal treats manually-added labels identically.

The scan only examines up to 200 most-recently-updated open PRs per run and makes ~2-3 API requests per unlabelled PR, keeping a full sweep of the current backlog (~124 open PRs) comfortably within the GITHUB_TOKEN rate budget.

Possible follow-up, not included here: automatically closing PRs that keep the label for an extended period, following the approach of #2636 (actions/stale scoped with only-labels: 'awaiting response'). Left out deliberately as the issue notes this needs more consideration.

Existing Issue
Fixes #2637

Screenshots
N/A — this change only adds GitHub Actions workflow files, it doesn't affect the CyberChef UI.

AI disclosure
Used Claude Code (Anthropic) to help design and write these workflows. I have reviewed the logic myself and understand how it works.

Test Coverage
No automated tests apply since these are GitHub Actions workflows rather than application code. The event-driven removal workflow was verified end-to-end on a fork with a test PR from a second account: the label was correctly removed both when the author pushed a follow-up commit and when the author left a comment. The same testing confirmed that review-triggered labelling cannot work for fork PRs (read-only token), which motivated the scheduled scan. The scan workflow supports workflow_dispatch so it can be run manually and its per-PR decisions inspected in the run logs before the schedule takes over.

[alleria173]

Hi there. Let me know if you need any more commentary/tests to support this pull request.

[sylvesterkaczmarek]

Inline review-thread replies are not treated as an author response. The removal workflow only listens to issue_comment, and the scheduled scan only checks issues.listComments; replies made in Files changed/review threads are pull_request_review_comment events and are returned by the review-comments API instead. An author can therefore answer every requested change inline and still get (or keep) awaiting response. Could we handle pull_request_review_comment in removal and include review comments in the scheduled response check?

[alleria173]

Good catch, thanks - fixed in e5668f0.

You're right on both counts:

• awaiting-response-label.yml now also triggers on pull_request_review_comment and clears the label when that inline reply is from the PR author.
• awaiting-response-scan.yml now also fetches review comments (pulls.listReviewComments) since the last CHANGES_REQUESTED review, in addition to top-level issue comments, when deciding whether the author has responded.

I don't have a good way to exercise these against real GitHub events before merge, so I extracted both embedded scripts and ran them against mocked context/github/core objects covering: an author-only inline reply (previously missed, now correctly clears/avoids the label), a non-author inline reply (label correctly stays), and the existing top-level-comment/no-response paths (unchanged). Happy to add anything else you'd want covered.

[sylvesterkaczmarek]

Rechecked e5668f08. Inline author replies are now handled in both places that matter: the event workflow listens for pull_request_review_comment, and the scheduled scan includes pulls.listReviewComments after the latest changes-requested review. This closes the false awaiting-response path I raised without changing the existing top-level comment/push behavior. No remaining blocker from me.

[GCHQDeveloper581]

Checked for security issues, especially given it uses pull_request_target.

• none seen

Looks good, but very hard to test without actually deploying it.

We'll roll it out and revert if it causes unforeseen problems.

Thanks for contributing.