-
Notifications
You must be signed in to change notification settings - Fork 499
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
JSON: Memo: An empty "memo" is not being generated for a transaction even if "memo_type" is "text" #149
Comments
I created this test: @Test
public void testTransactionEnvelopeWithEmptyMemoText() throws IOException {
String transactionEnvelopeToDecode = "AAAAABbxCy3mLg3hiTqX4VUEEp60pFOrJNxYM1JtxXTwXhY2AAAAZAAAAAMAAAAFAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAJAAAAAAAAAAHwXhY2AAAAQGCy99saUm6alXIRyp0NNh2OFSCybp1JGPDN2pb/+Fw07/X7y4lPEp/B6WIV130a+2eY+5T3ujbiKa6TIcUaNwQ=";
Base64 base64Codec = new Base64();
byte[] bytes = base64Codec.decode(transactionEnvelopeToDecode);
TransactionEnvelope transactionEnvelope = TransactionEnvelope.decode(new XdrDataInputStream(new ByteArrayInputStream(bytes)));
assertEquals(MemoType.MEMO_TEXT, transactionEnvelope.getTx().getMemo().getDiscriminant());
assertEquals("", transactionEnvelope.getTx().getMemo().getText());
} and it's working fine. Could you provide a code that throws null reference exception? |
OK, I understand what's the issue. This is happening because of the way This is fixed in lightsail-network/java-stellar-sdk#54. |
IMO, the |
I agree, if the memo_type is "none", then and only then should the memo field be missing. Seems like a bug in Horizon. |
+1 on the to @bartekn's comment, should we disallow an empty value for the |
Core accepts such transactions so we probably shouldn't do it. I was thinking more like: there's no easy way to fix this in |
@nikhilsaraf we can't disallow empty text memos. It's valid in the core protocol and I imagine it will remain that way. No memo is a distinct value from a text memo that's an empty string. Basically, we need to extract https://github.com/stellar/go/blob/master/services/horizon/internal/resource/main.go#L238-L239 into another struct that can more tightly control the encoding behavior by defining an implementation of https://golang.org/pkg/encoding/json/#Marshaler edit: yeah, what @bartekn said 😛 |
Cool, thanks for clarifying. Agree with the separated struct with marshaler approach. |
Hey, @lechengfan and I would like to work on this! |
I'm going to start with an example JSON returned from Horizon using the following transaction:
1113f23c225495534b2fd589a037798155ea73ee68a418e74364c1a3be4a20d8
JSON:
Notice there is the "memo_type" element with the value of "text". This suggests there should be a "memo" element somewhere(because client SDKs don't allow null memos of type text). If we decode the envelope_xdr we can see there is indeed a MemoText in there, with a value of empty string.
This will cause issues when client SDKs try to deserialize this transaction from JSON. I have tested this in the official java-stellar-sdk and it does indeed throw a null reference exception.
The text was updated successfully, but these errors were encountered: