adds decode/3 with format option

[mw23]

This fixes a bug where decoding fails for a data that was encoded with a supplied schema_name and :plain format

If the encoded message starts with the magic byte (0x00) due to the data that was encoded, the wrong codec is selected by
https://github.com/Strech/avrora/blob/master/lib/avrora/encoder.ex#L76
when decoding it later.
This causes the decoding to fail sporadically dependent on the encoded data.

I propose to fix this by including an optional format argument to the decode function.

Example: New test case that broke before adding the format: plain parameter

  1) test when decoding plain message that starts with what looks like a magic byte (Avrora.EncoderTest)
     test/avrora/encoder_test.exs:405
     Assertion with == failed
     code:  assert key == "io.confluent.numeric_transfer"
     left:  3906769129
     right: "io.confluent.numeric_transfer"
     stacktrace:
       test/avrora/encoder_test.exs:411: anonymous fn/1 in Avrora.EncoderTest."test when decoding plain message that starts with what looks like a magic byte"/1
       (avrora 0.17.0) lib/avrora/resolver.ex:47: Avrora.Resolver.resolve/1
       (avrora 0.17.0) lib/avrora/resolver.ex:26: anonymous fn/1 in Avrora.Resolver.resolve_any/1
       (elixir 1.10.4) lib/stream.ex:572: anonymous fn/4 in Stream.map/2
       (elixir 1.10.4) lib/enum.ex:3686: Enumerable.List.reduce/3
       (elixir 1.10.4) lib/stream.ex:1609: Enumerable.Stream.do_each/4
       (elixir 1.10.4) lib/enum.ex:1027: Enum.find_value/3
       (avrora 0.17.0) lib/avrora/codec/schema_registry.ex:57: Avrora.Codec.SchemaRegistry.decode/2
       test/avrora/encoder_test.exs:437: (test)

[Strech]

Hi @mw23 👋🏼

Thanks a lot for your contribution, I appreciate it! Let me think a bit about proposed changes over weekends

[Strech]

Thanks for the patience @mw23 I've read the code one more time and I think I have something to rise.

decode/3 makes sense only for plain format because all the others must ignore the given option as they heavily rely on the message itself (registry – magic byte, of – special header byte) and it just doesn't make much sense.

At the same time, I think, we should be able to enforce decoding for the plain format to overcome the collision. But I think it should be done in some sort of special case (exception) and not become a generic approach which might confuse.

As a suggestion, maybe we should come up with decode_plain exceptional function or find another way to enforce the plain format

---

UPD: Also by guess format you never can end with plain format and maybe it makes sense to extract both encode_plain/decode_plain at all ... but I'm not sure

[mw23]

Hi @Strech, thank you for considering this.

I see your point and agree that separate function(s) might be a way to go to make this cleaner so I went ahead and added encode_plain/2 as well as decode_plain/2 to have a mirroring API.

To your argument about handling this as exception in decode/2 - I think that might be less clean and could be a bit confusing to the user -- Our use-case would always be handled after an exception was raised in decode, which is a bit odd.

Please let me know what you think.

[Strech]

Thanks for your effort. I would like to request one thing in addition to the comments.

Can you two made up calls here to validate an external interface

[Strech]

May I ask you to follow the guideline for naming (it's not so important here, but oh my OCD) and rename the schema name to NumericTransfer

[mw23]

done

[Strech]

Maybe to emphasize the issue we can name it numeric_transfer_plain_message_with_fake_magic_byte

[mw23]

done

[mw23]

@Strech Thanks for your review. I incorporated the changes you requested.
I have struggled with enforcing the line length -- see my comment in the code above.

[Strech]

@mw23 Thanks a lot for such a quick update. Everything looks good to me. I will merge it on a Sunday 💙

[mw23]

@Strech - that's great news! Thank you!

[Strech]

Thanks @mw23 for your contribution! The changes you've proposed released in a v0.18 version 🎉 🍾