-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix: generation of debugIDs with invalid length #6144
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
fix: generation of debugIDs with invalid length #6144
Conversation
|
@pablomatiasgomez is attempting to deploy a commit to the rollup-js Team on Vercel. A member of the Team first needs to authorize it. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
💡 Enable Vercel Agent with $100 free credit for automated AI reviews |
lukastaegert
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean, nice work!
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #6144 +/- ##
=======================================
Coverage 98.72% 98.72%
=======================================
Files 271 271
Lines 10638 10638
Branches 2847 2847
=======================================
Hits 10502 10502
Misses 91 91
Partials 45 45 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
This PR has been released as part of [email protected]. You can test it via |
This PR contains:
Are tests included?
Breaking Changes?
List any relevant issue numbers:
Description
debugIDs are meant to be valid UUIDs (as stated in http://github.com/tc39/ecma426/blob/main/proposals/debug-id.md) but the current approach is, in some cases, producing invalid UUIDs that basically have a missing character. This happens because this was using a to_string function that first converts the hash to a int, and in cases with a leading zero, the conversion to hex chars will miss the leading zero (only happens for the first byte, leading zeros in subsequent bytes are handled correctly).
This change should only affect debugIDs that were invalid, other cases should still provide the same results. I changed one test that validates this:
The generated debugIDs were/are: