Closed joe-p closed 1 year ago
I'm not sure if this is strictly a bug. The SDK copies over the type definitions from go-algorand
, which defines a couple fields as map[uint64]
, e.g. StateProofTracking and LocalDeltas. If we change these to a map[string]
, we'd deviate from the go-algorand source code and trigger errors in cross-repo consistency checkers.
The other solution is to leave this part of the SDK as-is and defer struct parsing/JSON conversion to the client by letting them convert these two fields before using a json encoder. Interested to hear your thoughts as well.
I talked about this with @winder and it seems like this issue should be fixed once https://github.com/algorand/go-codec/pull/4 is merged and available in the sdk
That sounds good, I forgot that our codec repo was mega out of date.
Different flavor of the same issue but posting here for clarity and posterity's sake... basically any map that has a non-string key type will not get properly encoded. This affects other maps with integer keys like local deltas, but also more complex keys. For example, Txleases
:
"Txleases": {
{
"Lease": "PwvoKrpv440AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"Sender": "pFRedFkfkmKiIT+/WF/OEujrmHGIhB3HTP0uXHCPdKE="
}: 29701261
}
After looking into it a bit more https://github.com/algorand/go-codec/pull/4 will fix the encoding for numeric keys, so local deltas, createables, and spt, but there will still be a problem with encoding LedgerStateDelta.Txleases
because the key is Txlease
.
From the ecnoding/json docs:
Map values encode as JSON objects. The map's key type must either be a string, an integer type, or implement encoding.TextMarshaler.
This means Txlease
will need to implement TextMarshaler
and TextUnmarshaler
cc @Eric-Warehime about the txlease issue
Subject of the issue
When encoding a
Block
,StateProofTracking
inBlockHeader
is not encoded properly.Your environment
github.com/algorand/go-algorand-sdk/v2 v2.0.0-20230531123858-3a0efd6a6398
Steps to reproduce
Block
using the SDKs json encoder (example)Expected behaviour
JSON is valid
Actual behaviour
JSON is invalid
Note the key under
spt
is0
. JSON keys should be wrapped in double quotes