Creating check runs via API - can I assume that the returned check ID is strictly increasing? #46793
Replies: 1 comment
-
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Question
Body
Hey all, we're building an agent that takes certain actions on repositories and PRs based on the result of custom checks that the agent is responsible for running. The agent involves multiple workers that run in parallel, and we want to ensure that only one worker operates on a given repo, so our workers examine the current check runs on a given PR and bail out if another worker has already created the same check - effectively using check runs for synchronization.
The crux of this logic is that a worker creates a check run, then looks for all other check runs on the PR. If it sees that another check run for the same check has been created, and that run has a lower ID than its own, it cancels its own check run and bails out to let the other worker proceed. But this logic is flawed if it's possible for the Check Runs API to return IDs in a non-increasing order. Is that something we need to worry about, or can we assume that GitHub will issue strictly increasing check run IDs?
Beta Was this translation helpful? Give feedback.
All reactions