Improve RTM command behavior while CI checks are in progress

[princerajpoot20]

We need to improve RTM command behavior while CI checks are in progress.

The problem I am facing is that when reviewing a PR, it may look good and you want to merge it, but the branch is not updated. So when you go ahead and update the branch, you have to wait for quite some time until all the checks are finished (the testing workflow takes time). Only after all the tests passes, you can add the RTM command.

If you try adding the RTM command while CI is still running, the bot somehow removes the RTM label, and hence you need to add the RTM command again to merge it. An example of this happening is here: asyncapi/website#4823. The bot removes the RTM label, then you have to wait until all the mandatory checks are complete, and only then should you add the RTM command.

The problem with this is that you have to wait on that PR until the checks are passed, but there is no real point in waiting, as you have already checked that all the CI was passing when the branch was outdated. Updating the branch breaking the CI is highly unlikely, and even if it happens, the bot will simply not be able to merge it.

So, most of the time, you just wait until the checks are passed and then add the RTM command. We should handle this scenario such that if CI is running, it should wait until it is finished.

[Varadraj75]

Hello @princerajpoot20 ,

What I understand:

When CI checks are in progress, adding /rtm causes the ready-to-merge label to be removed by the workflow, so the merge intent is lost and must be re-added after CI completes.

The approach I can follow:

Make the ready-to-merge handling CI-aware so that the label is preserved while checks are running and only removed when checks fail, allowing RTM to wait for CI instead of being discarded.

[SHUBHANSHU602]

Hey , @princerajpoot20

As per my analysis, the workflow listens to pull_request_target events (synchronize and edited).

When these events occur, the workflow checks whether the PR has the ready-to-merge label and removes it unconditionally if present.

CI jobs also start running when the branch is updated, which makes it appear that CI is responsible for the label removal. However, the workflow does not check CI status at all—the label is removed purely due to the PR event, not because of CI results.

• Fix: Add logic to check CI status before removing RTM
• Before

• After:-
• 

What was changed

The workflow still runs on the same events: pull_request_target.edited and pull_request_target.synchronize.

The unconditional removal of the ready-to-merge label was replaced with CI-aware gating logic.

The workflow now:

checks whether the ready-to-merge label is present,

inspects CI check runs for the PR’s current HEAD commit,

removes the label only if at least one CI check has conclusively failed.

The label is not removed when CI is queued, in progress, passing, or not yet available.

[SHUBHANSHU602]

Hi, @princerajpoot20 @derberg , I’ve added my analysis above with supporting screenshots explaining why the ready-to-merge label is being removed ,what triggers it and a appropriate solution.

Could you please take a look and let me know if my understanding is correct?
If it looks good, I’d be happy to raise a PR to address this behavior.

Thanks!