Skip to content

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
merged 19 commits into from
Jun 27, 2025

Conversation

mkuratczyk
Copy link
Contributor

Test with OTP28

@mkuratczyk mkuratczyk force-pushed the otp28 branch 2 times, most recently from 2ad0d0f to 9016bcc Compare June 24, 2025 17:30
@mergify mergify bot added the make label Jun 24, 2025
@mkuratczyk mkuratczyk force-pushed the otp28 branch 2 times, most recently from ca7f6cf to d41d44f Compare June 26, 2025 09:40
@mkuratczyk mkuratczyk force-pushed the otp28 branch 2 times, most recently from 24ef634 to c3653d9 Compare June 27, 2025 09:29
mkuratczyk and others added 16 commits June 27, 2025 12:42
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 mkuratczyk force-pushed the otp28 branch 2 times, most recently from c6677c5 to 2a673da Compare June 27, 2025 12:30
@mkuratczyk mkuratczyk changed the title DO NOT MERGE: Use OTP28 in the pipelines Use OTP28 in the pipelines Jun 27, 2025
@mkuratczyk mkuratczyk marked this pull request as ready for review June 27, 2025 14:43
@michaelklishin michaelklishin added this to the 4.2.0 milestone Jun 27, 2025
Copy link
Collaborator

@michaelklishin michaelklishin left a 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!

@michaelklishin michaelklishin changed the title Use OTP28 in the pipelines Improve Erlang/OTP 28 compatibility, use OTP 28 in the pipelines Jun 27, 2025
@michaelklishin
Copy link
Collaborator

This also means that we will have to produce Elixir 1.18 Debian packages sooner rather than later but that's OK.

@michaelklishin michaelklishin merged commit f553775 into main Jun 27, 2025
1 check passed
@michaelklishin michaelklishin deleted the otp28 branch June 27, 2025 17:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants