-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Non-deterministic "Unexpected end of JSON input" from convert-source-map #8966
Comments
PRs welcome! |
Is this fix published to an alpha or beta version?? |
@SimenB when will we be able to get a version with this fix included? Thank you! |
Unfortunately, we're experiencing this as well in our test suite. So +1 from me on being interested in having this in a release :) Thanks folks, keep it up! |
+1 causing our build to fail 1 in 25 builds. which is quite a lot from a big R&D team perspective. |
@RajaBellebon we publish from master and this is merged, so yes, it's included. Look for a PR number that fixed it in the changelog: #9058 |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
π Bug Report
Using Jest 24.9.0 and ts-jest 24.0.2, we are getting non-deterministic build failures with this stacktrace:
The chance of any individual jest run failing this way is small, but due to the large number of projects in our repo, we are seeing it frequently in our CI builds.
The following bit of code is where the error happens:
The
fromSource
call results in an exception being thrown. Based on some added logging, convertSourceMap is trying to convert a comment with some base-64-encoded JSON into that JSON, but the comment is just cut off in the middle, resulting in JSON that fails to parse.I suspect the root cause here is some concurrency issue resulting in transformed.code containing an incomplete copy of the file that is cut off early. However, I'm interested in whether you'd accept a PR to address this at a shallower level in the meantime by catching exceptions thrown by
fromSource
and treating them the same as if it had returned undefined or an empty string. The code already handles the case where that happens, and the worst that would happen (AFAICT) is the absence of source mappings rather than an incorrect test failure.To Reproduce
I don't have a public repro for this issue. Our repo is large and proprietary, and the issue is non-deterministic. However, some aspects we believe are relevant:
--maxWorkers=4
Expected behavior
envinfo
(Note: This is occurring in a CircleCI container; the results below are from that environment.)
The text was updated successfully, but these errors were encountered: