Infinite loop makes changeset version command hang

[zkochan]

Affected Packages

@changesets/git

Problem

a loop that never ends
https://github.com/atlassian/changesets/blob/18d3da3b707fe834e0bb1cddce1186bb24b75ef2/packages/git/src/index.ts#L112

Proposed solution

[Andarist]

Even if there is a constant condition there this loop should not be infinite. There are multiple breaks in it and one of them should get hit by design. This is clearly a bug (it shouldn't hang) but I wouldn't blame this on this while statement per se.

Do you have some link to a repro case? Some GH action run perhaps?

[zkochan]

I don't have a repro currently because it hangs on a private repository in our Jenkins. But I know for sure that this is the part that hangs infinitely. When I changed that line to while (false), the publish proceeded.

[Andarist]

Would you be able to patch the content of this function with some extra console.logs and rerun the failing job to investigate this?

[zkochan]

deepenCloneBy() does not check if the git command was successful. It fails over and over and the loop continues indefinitly.

https://github.com/atlassian/changesets/blob/18d3da3b707fe834e0bb1cddce1186bb24b75ef2/packages/git/src/index.ts#L164-L166

[Andarist]

Ok, thanks - that is good to know! I will try to make sure to wrap all those git calls with some error handling unless somebody beats me to it.

[zkochan]

spawn will never throw an exception, it just returns a response with code != 0

[Andarist]

Yeah - I know. I've just referred to this kind of check as error handling. After all, if this would actually throw then there wouldn't be a problem as the while loop would be just terminated. And this is my actual plan right now: throw for code != 0. I would like to first learn more about why this fails in your case to decide if we should keep throwing or if we should simply return commit: null or smth in such scenarios.

[zkochan]

We run snapshot releases on pull requests and seems like there is no Git in the container that runs the release. Even if there is, I don't think fetching the history is a good idea as our repository is very big and it would cause a major slowdown. I think at least for snapshot releases it should not fail.

[Andarist]

@zkochan I've prepared a PR to fix the infinite loop: #584

I would still need to get a little bit more information about your setup to address this in a better way. Is your workflow file public so I could take a look at it?

[zkochan]

No, it is not public.

It is a project that uses git shallow cloning. It appears that the Git CLI was present. I can't investigate it further because I already spent a lot of time on it and the fork that I created solves the issue.

The lack of debug information made it impossible to investigate (I tried the --verbose flag). If some debugging info will be added, it will be easier to figure out the reason next time.

[fivethreeo]

I also get a infinite loop with all packages fixed in pre mode.

yarn changeset pre enter alpha

Running with debugger

node --inspect-brk node_modules/@changesets/cli/bin.js version

chrome://inspect

Seems to loop forever in assemble-release-plan

[Andarist]

@fivethreeo could you share a repro case? It's hard to debug this & fix it for me without one

[fivethreeo]

https://github.com/jaredpalmer/razzle/tree/alpha

[Andarist]

Thank you for the link - could you list your exact repro steps though? You have mentioned running yarn changeset pre enter alpha but this just results in:

$ /workspace/razzle/node_modules/.bin/changeset pre enter alpha
🦋  error `changeset pre enter` cannot be run when in pre mode
🦋  info If you're trying to exit pre mode, run `changeset pre exit`
error Command failed with exit code 1.

[fivethreeo]

I already ran that, just run yarn install and the version command.

[fivethreeo]

releasesValidated seems to never become true in the while loop

[fivethreeo]

dependentAdded and fixedConstraintUpdated are always true. I forced them to be false in debugger and version completes successfully.

[fivethreeo]

so I think releases get mutated by both determineDependents and matchFixedConstraint for every while loop

[fivethreeo]

If I remove fixed from config it works

[Andarist]

Thanks for looking into this - I should have a fix for this soon-ish

[echo99]

Any updates on when the fix for handling the git errors will be merged? I'm running into this issue as well when the git fetch --deepen call fails.

For my particular use case, I was running into the error fatal: error in object: unshallow which I was able to fix with a git repack -d, but it would be nice if changeset version showed the error instead of hanging.