[AlesProkop]

Context

Follow-up to #14470. The /freeze /unfreezecommand workflow only requestedissues: write, but it reacts to and replies on the *triggering comment*. When a command is issued from a **pull request** comment, GitHub requires pull-requests: writefor those operations, so the best-effort acknowledgement (👍 reaction + confirmation reply) failed withHTTP 403. The freeze/unfreeze state change itself always succeeded; only the acknowledgement on PR comments was affected. Confirmed live during rollout testing (a /freeze` from a PR comment applied the freeze and stamped the required status red, but posted no ack).

Changes Made

• Added pull-requests: write to the command job permissions in branch-freeze-command.yml so reactions/replies succeed when the command originates from a PR comment. This also covers the deny-command step (same job).
• Changed Add-Reaction in handle-command.ps1 to log a ::warning:: instead of silently swallowing a failed reaction, so any future permission gap is diagnosable.
• Tightened the adjacent permissions comment (removed the now-inaccurate pull-requests: read note; statuses: write remains scoped to the refresh job).

Testing

• Ran pwsh .github/branch-freeze/tests/run-tests.ps1: 73 passed, 0 failed.
• Validated PowerShell parser over .github/branch-freeze/** (*.ps1/*.psm1): no errors.
• Parsed branch-freeze-command.yml with powershell-yaml: valid; command-job permissions now {contents: read, issues: write, pull-requests: write}.

Notes

• Behavior when commanded from a regular issue comment was already correct and is unchanged.
• The deny-command path already logged reaction failures via Write-Warning and needs no change beyond the shared permission.

[Copilot]

Pull request overview

Updates the branch-freeze slash-command workflow to ensure acknowledgements (reactions/replies) succeed when the triggering comment is on a pull request, and improves diagnosability when reactions fail.

Changes:

• Granted pull-requests: write to the workflow’s default token permissions so the command job can react/reply on PR-originating comments without HTTP 403.
• Updated Add-Reaction to emit a GitHub Actions ::warning:: when adding a reaction fails, instead of silently swallowing the failure.
• Adjusted the permissions comment to reflect the new least-privilege breakdown (keeping statuses: write scoped to the refresh job).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
.github/workflows/branch-freeze-command.yml	Adds pull-requests: write to enable reactions/replies when /freeze is triggered from PR comments; clarifies permissions comment.
.github/branch-freeze/workflows/handle-command.ps1	Logs a workflow warning when reaction posting fails so permission gaps are visible in CI logs.

[github-actions]

Review Summary

This is a straightforward GitHub Actions workflow fix. Both changes are correct and low-risk.

Permissions (pull-requests: write)

The issue_comment event fires for both issue and PR comments, but the issues: write permission only covers reactions/replies on issue comments. Adding pull-requests: write is the correct fix to allow the bot to react/reply when /freeze or /unfreeze is invoked from a PR comment. This follows least-privilege: the permission is scoped to this specific workflow with a concurrency guard.

Warning annotation

Replacing a silent return with Write-Host "::warning::..." is a good improvement—failures to add reactions are non-fatal but should be visible for debugging. The message is clear and includes the relevant context ($Content, $CommentId).

Minor observation

The catch block no longer contains return, so execution will continue after the warning. This is fine since Add-Reaction is a fire-and-forget helper and callers don't depend on its success, but worth confirming that no code after an Add-Reaction call assumes the reaction was actually posted.

No blocking issues found.

Warning

Firewall blocked 2 domains

The following domains were blocked by the firewall during workflow execution:

• awmgmcpg
• patchdiff.githubusercontent.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"
    - "patchdiff.githubusercontent.com"

See Network Configuration for more information.

Generated by Expert Code Review (on open) for #14495 · 36.7 AIC · ⌖ 5.05 AIC · ⊞ 5K