-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Support hex strings to prevent broken log lines #13128
base: main
Are you sure you want to change the base?
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Thanks for the PR! Please sign the CLA and we can take a look. |
Closing due to missing CLA. We can reopen when ready. |
Hi @paulb777 apologies, we finally got the CLA resolved! That check is now green. |
Thanks @ls-todd-lunter! - Please address the code style issues showing up in the check CI - Most likely from four-space vs two-space indenting. |
aa41ae9
to
53520d3
Compare
53520d3
to
a6bd5b6
Compare
Rebased on main to see if it resolves the test failure. Otherwise, I don't think my logging changes would've affected the |
@wu-hui PTAL |
Discussion
While trying to record Firestore logs within our app, we started to notice many log lines were being reported as
(null)
in the Console. This seems to be because when logging the reference to the C++ objects, the%s
format was adding non-UTF8 encodable characters into the string. This meant when usingMakeNSString
in the Firestore logger, those non-UTF8 characters failed the string initialization, and it returnsnil
.Since there is already quite a lot of use of
absl
in the repo, I figured we could quick-win, use that to convert the string to hex and record that instead. I suspect logging the object was meant just to see if the value drifted overtime, rather than anything intrinsic to the object itself, so the hex value should do the same thing.Testing
I only added a test for the record hex value itself. Otherwise, it will behave the same for other types.
API Changes
None, internal to the SDK.