fix symbol_code serialization bug in eosdart library

[chuck-h]

🗃 Github Issue Or Explanation for this PR. (What is it supposed to do and Why is needed)

fix serialization bug in eosdart library which prevented use of action data fields of type symbol_code.

This Rainbow test transaction executed ok from Anchor. https://telos.eosx.io/tx/5558814d4a4772fc8de2296dce6282c4e42d5424c52d24ee43c860c05be0bc6d

But using LW to scan the QR gives this error

✅ Checklist

• [x] Github issue Explanation details are up to date for people to QA.
• [x] I have tested all my changes.

🕵️‍♂️ Notes for Code Reviewer

Uint8List is a fixed-length type.

Not sure why this wasn't a problem before. No Seeds actions with symbol_code type? Change in Uint8List growability with some Dart update?

🙈 Screenshots

👯‍♀️ Paired with

"nobody"

[n13]

Without testing it, I would assume that it's not very common to pass around symbol code type.

I have never used symbol code, for example

The specific bug was in this code base in other places too, with the same error, so not surprised about this.

[n13]

I think our app is the only real user of EOS Dart.

This is also why we integrated these messy libraries directly into our codebase, so we can manage them better.

This is a case in point - this stuff was extremely complicated to debug when it was happening in an external lobrary, and hard to test the fix too, fixing the library, having a local version, pointing to the local version, etc etc. S

Thanks for the fix, good one. @chuck-h

[chuck-h]

@n13 Regarding application of _symbolcode, I have been using (contract + _symbolcode) as the unique identifier of a token. You can never really trust the precision info in symbol type to be right anyhow -- you need to check with the contract stats if you're actually going to use it. Using symbol makes sense within an asset type, though; it expresses the originator's intent.

[n13]

@n13 Regarding application of _symbolcode, I have been using (contract + _symbolcode) as the unique identifier of a token. You can never really trust the precision info in symbol type to be right anyhow -- you need to check with the contract stats if you're actually going to use it. Using symbol makes sense within an asset type, though; it expresses the originator's intent.

Yeah I agree

I would add in an asset type, precision is required otherwise you wouldn't know what "amount" means.

It prevents bad bugs that would come from using the wrong precision... so passing in the asset with precision causes errors if the precision is different from what's defined in the contract.

If it was only passing symbol code, relying on the contract for precision, then errors in precision would go unnoticed and cause the wrong transfers to be executed etc.