Azure / Azure/azure-rest-api-specs

assign-reviewers workflow fails to request azure-data-plane-api-reviewers team (HTTP 422 'Could not resolve to a node')

Open
#45,985 2 comments 0 reactions 1 assignee Claimed by @samvaity View on GitHub
Dominant language
TypeSpec
Stars
3.1k
Forks
5.9k
Avg merge
3d 2h
Merged PRs (30d)
424

Description

## Summary

The data-plane review assignment workflow (`Data-Plane API Review - Assign Reviewers`, `.github/workflows/data-plane-review-assignment.yaml`) fails to request the `@Azure/azure-data-plane-api-reviewers` team as a reviewer. Every real request attempt returns **HTTP 422** and the team is never attached, so no data-plane PR has ever received an automated team review request.

## Symptom

The `requestReviewers` call in `assign-reviewers.js` fails:

```
POST /repos/Azure/azure-rest-api-specs/pulls//requested_reviewers
body: {"team_reviewers":["azure-data-plane-api-reviewers"]}
-> HttpError: Validation Failed: "Could not resolve to a node with the global id of 'T_kwDOAGhwUs4BIPhU'." (status 422)
```

Observed on real runs, e.g. PR #45863 (run 33450494798) and PR #45623 (run 33450861971), both `pull_request_target: labeled` runs that reached the request step and errored.

## What we ruled out

- **Team exists**: `azure-data-plane-api-reviewers` ("Azure Data Plane API Reviewers"), privacy `closed`, 13 members.
- **Team has repo access**: `pull/push/triage = true` on `Azure/azure-rest-api-specs`.
- **The id is correct**: the failing global id `T_kwDOAGhwUs4BIPhU` is exactly the team's current `node_id` -- so GitHub is failing to resolve the *correct* team, not a stale/wrong reference.
- **Not the migration window / not the dedup logic**: current on-main `assign-reviewers.js` runs and reaches the API call; it just 422s there.

## Likely root cause

The workflow uses the default Actions `GITHUB_TOKEN` (installation token; permissions `PullRequests: write`, no org/team read). A `closed`-privacy org team appears not to be resolvable as a reviewer in that token's context, so the request 422s. A **user/maintainer session can request the same team fine** -- verified manually on #45863: requesting the team from the PR UI succeeded, created the durable `review_requested TEAM` event, and native code-review auto-assignment delegated to a member (kashifkhan).

## Impact

- No data-plane PR gets an automated team review request; the review queue relies on manual reviewer assignment.
- The `pull_request_target: labeled` runs surface as red (failed) on affected PRs.

## Proposed fix (options)

1. Request the team using a token that can resolve org teams (e.g., a GitHub App installation token with `members: read`, or a scoped PAT), instead of the default `GITHUB_TOKEN`.
2. Confirm whether team privacy / visibility to the Actions app is the blocker and adjust accordingly.
3. Make the request resilient: catch the 422 and log actionable context rather than failing the run.

## Repro

1. Apply `data-plane-review-requested` to an open data-plane PR (or re-toggle it).
2. Watch the `Data-Plane API Review - Assign Reviewers` run -> it fails at the `requestReviewers` step with the 422 above.

## Workaround (per-PR)

Assign the team manually from the PR Reviewers panel (a maintainer session resolves the team; auto-assignment then delegates to a member). This also creates the durable team event, so the workflow dedups and stops retrying for that PR.

## Parent

Part of #45437 (data-plane review label consolidation).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.