Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Race condition in the diff.yml workflow #3470

Open
gouttegd opened this issue Jan 29, 2025 · 0 comments
Open

Race condition in the diff.yml workflow #3470

gouttegd opened this issue Jan 29, 2025 · 0 comments
Assignees
Labels

Comments

@gouttegd
Copy link
Collaborator

gouttegd commented Jan 29, 2025

The diff.yml workflow (aka the gogoeditdiff workflow) automatically runs whenever someone comments on a PR, to check whether the comment includes the keyword #gogoeditdiff -- if that’s the case, then the workflows goes on to generate a diff of the ontology between the current master branch and the PR’s branch.

Some steps in that workflow critically require the PR to be in the open state to work -- if the PR is closed (whether it is because it has been merged or, on the contrary, rejected), they fail loudly with a Cannot read properties of null (reading 'name') error.

To prevent this error from happening, there is already a guard rail in place (#3437) that ensures the workflow only runs on non-closed PR.

Unfortunately, that’s not enough. If someone writes a comment and then almost immediately after closes the PR, the diff workflow will still be triggered as soon as the comment is written, but by the time the execution flow reaches the comment-branch step, the PR will be closed and the step will loudly fail.

This has happened for example on PR #3469, where I added this comment and almost immediately merged (and so, closed) the PR, resulting in this failure of the diff.yml workflow.

Not sure what we can do here -- testing that the target PR is not closed is of no use (we are already doing that, but it does not catch the fact that the PR might be closed shortly after the workflow has started).

@gouttegd gouttegd added the tech label Jan 29, 2025
@gouttegd gouttegd self-assigned this Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant