-
Notifications
You must be signed in to change notification settings - Fork 924
Add assertion IDs that will be included in production log statements for fail and hardAsserts #8313
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
Conversation
…d of removing error messages.
🦋 Changeset detectedLatest commit: 833f972 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Changeset File Check ✅
|
Size Report 1Affected Products
Test Logs |
IMO adding 2.4 kB to the bundle size is questionable if it's worth it. |
Size Analysis Report 1This report is too large (723,339 characters) to be displayed here in a GitHub comment. Please use the below link to see the full report on Google Cloud Storage.Test Logs |
@dconeybe, in your opinion, what increase in bundle size would be acceptable? It's <=1% increase, which seems like a reasonable tradeoff for making production issues more debuggable. But I'm seeing if I can make the impact smaller. |
I'd hope it would be less than 1kB. But this is just one man's opinion. Please don't take it as gospel truth. |
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.
This is fantastic! I especially like how you added the "context" which will be incredibly useful when debugging. Thanks for doing this, Mark.
Please let the team know about the 1% increase in code bundle size and make sure they're ok with it. The "firestore (Read Write w Persistence)" bundle increased by 2.77 kB which is probably worth it, but I'd make sure the team knows. Also, please add a change set with a minor version bump and a change log entry. |
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.
Reminder to add a changeset if you want it to publish.
FWIW I much prefer the "hashes" you had before over error codes numerically incrementing from zero. The reason is that hashes have much better "SEO" because of their uniqueness. Firstly, the improved SEO allows customers to search for the error code and find relevant bug reports, stack overflow posts, etc. If they search for error code "3" they won't likely get anything useful, but if they search for "jszxcbe37k" they'll likely get results that relate directly to the error that they are experiencing. Likewise, when we as Firestore SDK developers get a bug report with error code "3" it's much more difficult to find its place in the source code than searching for "jszxcbe37k". For Data Connect I chose this alphabet: |
…value programatically as an error code
…ase-js-sdk into markduckworth/error-codes
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.
Mostly LGTM. Just a few minor comments. Thanks for doing this work! I'll formally "approve" once the comments are addressed/refuted.
…ase-js-sdk into markduckworth/error-codes
Vertex AI Mock Responses Check
|
In the Firestore SDK, error messages are removed from
fail(message)
andhardAssert(condition, message)
statements during the build. Removal of error messages is performed to reduce bundle size, however this comes at a cost to usability. Specifically, this means that production error messages can be unhelpful.Here's an example of a production error message today (without this change):
"Unexpected state" is the same reason given for 130+ error conditions after the detailed error messages have been stripped.
To improve debuggability of error messages, this PR adds a numeric assertion ID to each
fail
andhardAssert
statement. These numeric IDs are unique and will not be removed from the build output. The full error message will still be removed during the build, but the assertion IDs introduced with this change will give customers and support more information to debug the output.Here's and example of a production error message after this change is applied:
Scripts:
yarn assertion-id:new
- Create a new unique IDyarn assertion-id:check
- Check for duplicate and invalid id formattingyarn assertion-id:find <ID>
- Find an existing ID and the error message associated with ityarn assertion-id:list
- list all of the existing IDs and their error messages