-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Improve Erlang/OTP 28 compatibility, use OTP 28 in the pipelines #14114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
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
2ad0d0f
to
9016bcc
Compare
ca7f6cf
to
d41d44f
Compare
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"], ```
c6677c5
to
2a673da
Compare
michaelklishin
approved these changes
Jun 27, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully the json
dependency conflict will be resolved soon.
Thank you for putting in all this work!
This also means that we will have to produce Elixir 1.18 Debian packages sooner rather than later but that's OK. |
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