prlint: non-CDK-team aws org members misidentified as maintainers, causing PRs to lose review labels
- 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
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