gzip test failure on macOS

[dantswain]

I've just recently started seeing this error:

  1) test create_request correctly encodes messages with gzip (KafkaEx.Protocol.Produce.Test)
     test/protocol/produce_test.exs:30
     Assertion with == failed
     code:  assert expected_request == request
     left:  <<0, 0, 0, 0, 0, 0, 0, 1, 0, 23, 99, 111, 109, 112, 114, 101, 115,
              115, 105, 111, 110, 95, 99, 108, 105, 101, 110, 116, 95, 116, 101,
              115, 116, 0, 1, 0, 0, 0, 10, 0, 0, 0, 1, 0, 16, 99, 111, 109, 112,
              114, ...>>
     right: <<0, 0, 0, 0, 0, 0, 0, 1, 0, 23, 99, 111, 109, 112, 114, 101, 115,
              115, 105, 111, 110, 95, 99, 108, 105, 101, 110, 116, 95, 116, 101,
              115, 116, 0, 1, 0, 0, 0, 10, 0, 0, 0, 1, 0, 16, 99, 111, 109, 112,
              114, ...>>
     stacktrace:
       test/protocol/produce_test.exs:47: (test)

I'm on macOS 10.13.1 with Erlang 20.1.7 from homebrew and elixir 1.5.2 from kiex. I'm not sure if this is an Elixir/OTP version problem or a mac problem. I just checked and we're not testing against 1.5.2/20.1 in Travis, which we should be doing. I'll open a PR to do that.

I did modify the test a bit to get it to tell me exactly which bytes were different:

     [{85, 79, 90}, {86, 44, 216}, {87, 46, 47}, {88, 209, 42}, {108, 3, 19}]

The format of this is [{byte number, expected byte value, got byte value}]. The expected and got binaries are the same length.

[dantswain]

#254 tested with Elixir 1.5.2 and OTP 20.1 did not reproduce this issue, so it seems to be specific to my setup.

[dantswain]

I get the same error with 1.5.1, and with 1.5.2 re-installed. I have wiped deps and _build between attempts.

It's possible these are equivalent gzipped data, maybe?

[bjhaid]

maybe print out the binary data and compare?

[dantswain]

@bjhaid I did (effectively) do that. That's where this came from:

[{85, 79, 90}, {86, 44, 216}, {87, 46, 47}, {88, 209, 42}, {108, 3, 19}]

Those are the bytes that are different ({index, got, expected} (i might have got/expected backwards)). I haven't worked back through the protocol yet to figure out what part of the message that is. It's clearly not the entirety of the binary data of the message.

[dantswain]

@joshuawscott was unable to reproduce this on his mac. He is not on high sierra and I am.

[bjhaid]

This commit erlang/otp@948ee9b modified the internals of the erlang gzip function, can you try using an OTP prior to any of this:

OTP-20.1.7 OTP-20.1.6 OTP-20.1.5 OTP-20.1.4 OTP-20.1.3 OTP-20.1.2 OTP-20.1.1 OTP-20.1

[dantswain]

@bjhaid I have a confirmed failure from someone running an OTP 20.0 release on High Sierra.

I think this may have to do with the linked version of zlib? With homebrew you can find out the version by doing something like this:

cd /usr/local/Cellar/erlang/<whatever version you're using>/lib/erlang/erts-<whatever version it is>/bin
otool -L beam.smp

I don't know if it's that the version has changed or that the version shipped with High Sierra is somehow different. This is not even necessarily a bug - I think we need to grab the message components out of the binary and see if they decompress correctly.

[bjhaid]

I think we need to grab the message components out of the binary and see if they decompress correctly.

👍

[dantswain]

OK, I did quite a lot of digging here and I'm pretty sure that the only difference is in the zlib header, and that it won't cause any problems. I'm going to try to figure out a way to change the tests that still tests the functionality but won't fail when zlib changes.

[dantswain]

Closed by #256