Issue labeling logic needs tweak to be compatible with project workflow

[jithunnair-amd]

We use the following project workflow to track and organize ROCm-related PyTorch issues:
https://github.com/orgs/pytorch/projects/38/workflows/12300629

As you can see, we try to exclude issues with the skipped label since those are a different category of unit-test skips which we don't want to include in the project.

However, for any such issues, it looks like the bot labeling logic works in the following order today:

1. Add skipped label (based on DISABLED in the title)
2. Add module: rocm label (based on platforms: rocm in the description) and remove skipped label
3. Add skipped label again (based on DISABLED in the title)

Unfortunately, due to the order in which the labels are added, the project workflow kicks in between step 2 and 3, and ends up adding these issues to the project before the skipped label is re-added. It's a race condition, but I think a simple fix to this could be to reverse the order of labels in the list to be added: First add the already-existing labels, followed by the (new) platform labels.

An example of this race condition in action: pytorch/pytorch#125991

IIUC, the relevant code is here:

test-infra/torchci/lib/bot/verifyDisableTestIssueBot.ts

Line 293 in e17cace

await context.octokit.issues.setLabels({

Can we please reorder the labels so that this race condition doesn't occur?

[hongxiayang]

Thanks @jithunnair-amd for filing this issue. This will help to reduce the noises in the "Pytorch for ROCm" project.

[ZainRizvi]

Sounds like the core problem is a race condition, where:

• Process A reads the labels
• Process B adds a label
• Process A writes back the original set of labels, adding a new. one, and overwrites the label that project B added

Fix could be to use a different github API to only append a new label instead of setting the full list of labels

[jithunnair-amd]

@ZainRizvi I agree that if there's a way/api for appending instead of setting labels, that'd be ideal in this scenario.