Improve Erlang/OTP 28 compatibility, use OTP 28 in the pipelines #14114
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mkuratczyk
force-pushed
the
otp28
branch
2 times, most recently
from
2ad0d0f to
9016bcc
Compare
mkuratczyk
force-pushed
the
otp28
branch
2 times, most recently
from
ca7f6cf to
d41d44f
Compare
mkuratczyk
force-pushed
the
otp28
branch
2 times, most recently
from
24ef634 to
c3653d9
Compare
1. OTP28 changed sslsocket structure 2. an old hack is no longer necessary
Test case two_nodes_different_otp_version was introduced in #14042. In CI, the code was compiled on OTP 27. The test case then applied the Ra commands on OTP 27 and OTP 26 at runtime. For that to work the test transferred the compiled BEAM modules to the OTP 26 node. Bumping OTP to 28 causes the lower version node (be it OTP 26 or OTP 27) to error when parsing the atom table chunk of the BEAM file that was compiled in OTP 28: ``` corrupt atom table {error,badfile} ``` That's expected as described in erlang/otp#8913 (comment) since erlang/otp#8913 changes the atom table chunk format in the BEAM files. ``` beam_lib:chunks("deps/rabbit/ebin/lqueue.beam", [atoms]). ``` will parse successfully if the file gets loaded on OTP 28 irrespective of whether the file was compiled with OTP 27 or 28. However, this file fails to load if it is compiled with 28 and loaded on 27. There is the `no_long_atoms` option that we could use just for this test case. However, given that we have a similar test case two_nodes_same_otp_version we skip test case two_nodes_different_otp_version in this commit. Really, the best solution would be to use different OTP versions in RabbitMQ mixed version testing in addition to using different RabbitMQ versions. This way, the test case could just RPC into the different RabbitMQ nodes and apply the Ra commands there.
Elixir 1.18 comes with a JSON package which leads to errors like this:
```
Duplicate modules: [["/home/runner/work/_temp/.setup-beam/elixir/bin/../lib/elixir/ebin/Elixir.JSON.Encoder.Float.beam",
"/home/runner/work/rabbitmq-server/rabbitmq-server/deps/json/ebin/Elixir.JSON.Encoder.Float.beam"],
```
mkuratczyk
force-pushed
the
otp28
branch
2 times, most recently
from
c6677c5 to
2a673da
Compare
mkuratczyk
changed the title
michaelklishin
approved these changes
Jun 27, 2025
Collaborator
michaelklishin
left a comment
michaelklishin
left a comment
There was a problem hiding this comment.
Hopefully the json dependency conflict will be resolved soon.
Thank you for putting in all this work!
michaelklishin
changed the title
Collaborator
|
This also means that we will have to produce Elixir 1.18 Debian packages sooner rather than later but that's OK. |
Collaborator
|
Debian and RPM packages now mark Erlang/OTP 28 as supported (for RabbitMQ 4.2 only): rabbitmq/rabbitmq-packaging#57 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Test with OTP28