Client#submit_tx.: Fix Base64 encoding#96
Conversation
joallard
changed the title
|
@joallard Thank you for the quick update! I know it's a lot more back and forth than you would expect for a one-liner change, but it seems that Rubocop is unhappy now because the single-quoted string literals violate the standard style guide we're adopting for this SDK (in case you're interested, we have a blog post which outlines the reasons behind this practice). Both double-quoted string literal and symbol would be in line with a style guide, although using |
|
No problem, I personally prefer up-to-the-notch code. I'll amend that real quick. |
Ruby's standard Base64.encode64 inserts newline separators by default, which Horizon doesn't accept.
|
Kudos, SonarCloud Quality Gate passed!
|
|
I also wholeheartedly agree that in this case, 'base64' is not semantically a string, but rather a symbol, as it's code rather than data. The case/when's on the other side, which I tried to match, had confused me ;) Gotta admire the commitment to real good code! (That said that makes me wonder about my other PR in which I took way more Ruby artistic license haha!) |
|
Ah, good job on the cherry-picking and commit message rewording @nebolsin, this is very well phrased. It's the little things, as they say! |
|
Very nice catch on this regression. Thank you! 👍 |
2 participants
Without strict, produces newline characters which Horizon will reject
(Split from #95:)
And so I was getting some TransactionMalformed errors. Looks like this is because Base64.encode64 by default inserts some newlines, which Horizon doesn't like.
The tests probably didn't catch this because of some combination of using VCR and upgrades on our side.