@melink14 ,

Yes, there is not any events or activity types of the pull_request_review_comment event for resolving the conversation.
I tested and tried, however I did not find any other workarounds.

If your projects really need this feature, I recommend that you can directly report a feature request here. That will allow you to directly interact with the appropriate engineering team, and make it more convenient for the engineering team to collect and categorize your suggestions.

Thanks, brightran, for trying to see if there were some workarounds.

I left feedback for this usecase via the feedback form.

I hope as the code review abilities become more mature this type of functionality will be prioritized. :slight_smile:

@melink14 ,

I hope as the code review abilities become more mature this type of functionality will be prioritized.

Yes, I agree that.

In addition, you also can follow the “GitHub public roadmap” repository where you can learn about what features the appropriate engineering teams are working on, what stage the features are in, and when the teams expect to bring them to you.

When the new features are published, you can view the release note from “GitHub Changelog”.

I created the following GitHub Action to prevent the merge of a pull request with unresolved review threads. The flow is far from perfect, but it’s a start! Hope it is of any help!

Thanks for the update @SamuelCabralCruz. I may try it out. I’ve just been working on this as well using composite actions but I like the idea of using a label to work around the lack of event for comment resolution.

One thing to note is that your action may fail for PRs from external forks since GitHub recently restricted those workflows to read only.

In the case of adding labels we can use pull_request_target instead but that may not work for things like pull_request_review_comment or pull_request_review.

Though the docs are not clear on this so it will take some experimentation.