SNOW-1901636 exclude \0 from the serialized CJSON #826
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sfc-gh-dprzybysz
approved these changes
Feb 4, 2025
|
Please set issue id in PR name |
sfc-gh-mkubik
changed the title
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #826 +/- ##
==========================================
+ Coverage 80.43% 80.53% +0.09%
==========================================
Files 104 104
Lines 9222 9223 +1
==========================================
+ Hits 7418 7428 +10
+ Misses 1804 1795 -9 ☔ View full report in Codecov by Sentry. |
sfc-gh-mmishchenko
approved these changes
Feb 5, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
During
vector<char>serialisation we keep the trailing\0symbol but it seems that the result is only used as vector so there's no need to keep the end of string as a separate character. Currently this char is being passed to Base64 encode function during JWT creation which results in invalid JWT that cannot be processed properly by the new library that backend is going to use