-
Notifications
You must be signed in to change notification settings - Fork 17
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
bug: transaction information comes base64 encoded #1354
Comments
ping @mvdan |
Sorry for the slowness. I looked into this recently but got stuck; these are Go types generated as part of our protobuf models, so they hard-code the field types and we are not able to use our own Copying the types to replace those field types would be a nightmare, since the tx type is a oneof, so we would need to copy over a dozen types. Protobuf themselves do not provide any way to configure how the JSON marshaling happens, because the spec says that bytes MUST marshal as base64 in JSON: https://protobuf.dev/programming-guides/proto3/#json Trying to do some patching via encoding/json and The only realistic solution I can think of would be to use Go reflection to recurse the models.Tx value, find all The only alternative I can think of is to keep base64, and very clearly document that the In the meantime, here are two commits to clean up the code a bit and add a test: #1374 |
A third option would be for the REST endpoint to provide a JSON field containing the original protobuf-encoded bytes, in binary format encoded as base64. Then it would be up to the frontend to use the protobuf library to decode those bytes into the |
ping @altergui |
Let me know what the resolution here is, I'm happy to assist on the Go side if any changes are needed. |
that's not an option because it's basically what we've been doing until now, the problem is that not ALL fields are base64 encoded, some are simply integers (like 1000) that nonetheless can be parsed as base64, but they shouldn't. so it's not simply saying |
that's clever! i tried using reflection to modify the types of the original object (before passing to protojson marshal) but that didn't go well. didn't think about leaving the object untouched, love it. |
Then I think the best remaining option is to do some reflect magic on the Go side to find all
To be clear, that is a problem with either base64 or hex encoding. |
precisely because of that consistency. yes, please do the reflect magic 🙏 fwiw, i agree "123" can be a string or hex-encoded bytes, you're correct. but explorer doesn't care, the hex-encoded bytes are useful, they can be treated as a string. problem is with base64, it's useless unless converted to base16, and that conversion is problematic. |
Done: #1393 |
Describe the bug
The transaction information endpoint
v2/chain/transactions/{blockHeight}/{transactionIndex}
is returning most information base64 encoded.Due to this base64 encoding, the explorer was trying to decode everything, and that was causing the error in vocdoni/explorer/issues/62
To Reproduce
curl -s https://api-stg.vocdoni.net/v2/chain/transactions/1176690/0 | jq
Calls where we found base64 data instead of base16 (expected):
processId
andcensusRoot
)https://api-stg.vocdoni.net/v2/accounts/ab90d6c3a9b65d6c90830480e4b75ad32e747942/transfers/page/0 (fieldalready fixed by @altergui.txHash
)Current behavior
The returned json has many base64 values:
Expected behavior
To receive all these base64 values as base16
The text was updated successfully, but these errors were encountered: