Go-flutter: Faulty alignment in plugin.StandardMessageCodec

[erickzanardo]

Hello I am trying to port the audioplayers plugin to go-flutter and have been facing some problems that I can no longer solve alone.

When I call the play method on the plugin, I receive the following error:

go-flutter: handling message on channel xyz.luan/audioplayers failed: failed to decode incomming message: failed decoding method arguments: invalid message value type

I have tried looking into go-flutter source code, and it looks like some arguments that are sent from the dart is breaking the conversion function of go-flutter. That is my guess, but I am a total novice on Go so I may be very much wrong.

Flutter version

Flutter 1.6.7 • channel dev • https://github.com/flutter/flutter.git
Framework • revision cba41ca2ec (5 days ago) • 2019-05-30 12:04:01 -0700
Engine • revision 58eff77ef2
Tools • Dart 2.3.2 (build 2.3.2-dev.0.0 fee615c5a5)

Steps to Reproduce

I have committed the things I did so far:

This is our example app of the audioplayers plugin with the go-flutter already inited by hover: https://github.com/luanpotter/audioplayers/tree/go-flutter-desktop

Here is my fork of the plugins repository with the initial implementation of the audioplayers in go: https://github.com/erickzanardo/plugins/tree/audioplayers (so far it is just a bunch of printf calls and some tests with audio libs in go)

Just running the example app of the audioplayers repository and hitting play on any of the test players makes the error happen.

Thanks a lot for your time.

[pchampio]

From what I can tell, the volume value from the map sent to the platform is causing the standard-message-codec to fail.
When debugging, I found out that the readFloat64 method was the one causing the misinterpretation of the platform message.

When reading/writing a Float value, the flutter putFloat64 dart code is prefixing multiple alignment bytes to the Float64 value.
The number of alignment bytes seems to be miss calculated. I can't tell by who and why!

The number of alignment bytes calculated by go-flutter seems to be off by 2 bytes.

Again, why????
flutter-rs is doing it.
Android shell is doing it.
FDE MacOS is doing it.
FDE Linux/Windows is doing it.

Here is a visual:

I've put a ?bugfix? in a new branch bugfix/standart-message-codec, this skips 2 more bytes (The RED one in the above screenshot) before reading the Float64.

You can test the changes by running:

hover run -b '@bugfix/standart-message-codec'

This will allow you to carry on the plugin development. This isn't a fix!

BTW: It's fantastic to see work happening in the porting existing plugins. Also, it's even more fantastic to have feedback. Thanks. :1st_place_medal:

[erickzanardo]

Thanks for the quick response @Drakirus , I will test this tonight and report back here :)

[pchampio]

@GeertJohan Adding the buff.Next(2) breaks the unit test. We will need your help on this one.

[erickzanardo]

@Drakirus just reporting back, the branch you asked me to use work like a charm! thanks

[GeertJohan]

Auch, thats odd! I have scheduled some time to take a proper look at this bug next monday.
And @erickzanardo, really awesome to see go-flutter plugins come to life! :rocket:

[GeertJohan]

Thanks for sharing all this information and a working example. It helped me to identify the issue really fast.

You see, the problem is not directly with standard message codec, it works fine on it's own and the unit tests are happy. The problem is introduced when using the message codec from the standard method codec.
The standard method is a bit strange, it encodes a string as method name, directly followed by a single arguments value. The arguments value is a single value but it may be a string, int, float (etc) or a complex type such as a list or map, which allows passing "multiple arguments".

So, the method call data structure is as follows:
<methodName><arguments>
It is decoded by two separate calls to the standard message codec. First call to decode the methodName string from the buffer. Then a second call to decode the arguments value.

You probably see where this is going...
When decoding the arguments, the standard message codec has no knowledge of any values preceding the arguments in the buffer, which were decoded in the first call. So if a methodName of length != 8 is used, there is an offset that isn't properly compensated for.

I'm now working on a fix :)

[GeertJohan]

I've created a PR that includes proper unit tests for this situation: Simple unit test with several scenario's and a unit text containing a replica of the MethodCall that this issue was opened for. The PR also fixes the issue. ;)

[pchampio]

The fixe made by @GeertJohan solves the bug, the branch @bugfix/standart-message-codec is deleted.
The tag: v0.19.0 includes the fix.

[erickzanardo]

Thanks for the quick fix!