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.
Per: https://yugabyte-db.slack.com/archives/CG0KQF0GG/p1644257955047349?thread_ts=1643868640.696389&cid=CG0KQF0GG
Please interpret the resp.snapshot_id() as an array of 16 bytes. And nothing more. (Not md5/base64/etc.) 16 bytes. Each byte value is in: 0x00 - 0xFF range.
In C++ code the decoding only checks the string size and do memcpy:
Per: https://yugabyte-db.slack.com/archives/CG0KQF0GG/p1644258454859919?thread_ts=1643868640.696389&cid=CG0KQF0GG
Just because the Snapshot ID for non-transaction-aware-snapshot (old snapshot when "transaction_aware=false" - not used now) was passed through the same PB field. So, in the code "32-bytes string" = old non-transactional snapshot UUID as a string. "16 bytes" = new transactional snapshot id in binary form. So.. two-in-one.. it's the reason of the complexity. Sorry.
As the old (non-transactional) snapshots are not used more, you can always expect the 16 bytes.
The case is only for Snapshot ID.
Namespace/Table/Tablet ID is a UUID in simple string form. No such complexities.