aws / aws/aws-cdk

prlint: non-CDK-team aws org members misidentified as maintainers, causing PRs to lose review labels

Open
#37,862 1 comment 0 reactions 0 assignees View on GitHub
effort/medium feature-request p2
Dominant language
TypeScript
Stars
12.9k
Forks
4.6k
Avg merge
2d 3h
Merged PRs (30d)
83

Description

## Describe the bug

`prlint` treats any reviewer whose `author_association` is `MEMBER` as a CDK maintainer. Because this repository is owned by the `aws` organization, `MEMBER` matches **every AWS employee who belongs to the `aws` org**, not only the CDK team.

When a non-CDK-team org member approves a PR, `prlint` sets `maintainerApproved = true`, marks the PR as not needing review, and **removes both `pr/needs-community-review` and `pr/needs-maintainer-review`**. The PR then silently drops out of the review queue with no label to surface it.

## Where the bug is

[`tools/@aws-cdk/prlint/lint.ts#L73-L76`](https://github.com/aws/aws-cdk/blob/main/tools/%40aws-cdk/prlint/lint.ts#L73-L76):

```ts
const maintainerApproved = reviewsData.some(
review => review.author_association === 'MEMBER'
&& review.state === 'APPROVED',
);
```

The check conflates two different concepts:

- `author_association === 'MEMBER'` in the GitHub API means "member of the **organization that owns the repository**" (here: `aws`).
- "CDK maintainer" is a strict subset of that — the members of the `aws/aws-cdk-team` GitHub Team.

The rest of the repository already treats `@aws/aws-cdk-team` as the source of truth for maintainership (e.g. `.mergify.yml` uses `author=@aws/aws-cdk-team`). **`prlint` is the only place where this distinction is dropped.**

## Impact

- Any PR approved by an AWS employee who belongs to the `aws` org but is not on the CDK team loses both review labels and becomes invisible to maintainers.
- The state is sticky: subsequent `prlint` runs re-derive the same (wrong) conclusion, so the labels are never re-added on their own.
- `.mergify.yml` is unaffected (it doesn't rely on these labels), but discoverability by the maintainer team is broken — such PRs stop appearing in the usual label-based review queues.

## Reproduction

PR #37508 is a live example.

- At 2026-04-08 23:30:47Z, a **non-CDK-team `aws` org member** approved the PR.
- The `prlint` run at 2026-04-08 23:34 ([workflow run 24164141223](https://github.com/aws/aws-cdk/actions/runs/24164141223), [job 70522005198](https://github.com/aws/aws-cdk/actions/runs/24164141223/job/70522005198)) logged:

```json
{
"state": "APPROVED",
"author_association": "MEMBER",
"submitted_at": "2026-04-08T23:30:47Z"
}
```

and:

```
evaluation: {
...
"maintainerApproved": true,
"communityApproved": false,
...
}
```

- Because `maintainerApproved = true`, `assessNeedsReview` sets `readyForReview = false` and falls into the `else` branch that removes both `pr/needs-community-review` and `pr/needs-maintainer-review`. Roughly two minutes later (23:32:59Z), `aws-cdk-automation` removed `pr/needs-community-review`. Neither review label has been re-added on any subsequent run.

## Expected behavior

`prlint` should consider only CDK team members as maintainers when computing `maintainerApproved` / `maintainerRequestedChanges`, consistent with how `.mergify.yml` defines maintainership as `@aws/aws-cdk-team`.

Contributor guide

Open the contributing guide

Research direction

Start in tools/@aws-cdk/prlint/lint.ts around lines 73-76 and compare the maintainer definition in .mergify.yml. Use PR #37508 and its linked workflow logs as the reproduction, then verify that approvals and requested changes from only @aws/aws-cdk-team members determine the maintainer review labels.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, typescript
Domain
tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.