Circular dependency when upgrading to OTP-27 and RMQ 4.0.3

Questions / Help
,
1

I’m in the process of moving a large application from OTP 23.x to OTP-27

As part of this process I needed to upgrade RabbitMQ from an old 3.6 series to 4.0.3

When compiling, all goes fine, but when building a release it fails with error:

===> Error generating release: 
Circular dependencies among applications: [{amqp_client,"4.0.3"},
                                           {rabbit_common,"4.0.3"}]

The error originates from systools_make.erl where it’s trying to calculate start order of applications for generation of the boot script.

For the life of me I cannot figure out why it’s actually failing or how to fix it.

For reference, the applications sections from relevant apps:

a) My main app has our shared library app smlib in its applications
b) Our smlib library app has amqp_client in its applications
c) amqp_client

        {applications, [kernel,stdlib,xmerl,ssl,public_key,rabbit_common,credentials_obfuscation]},

d) rabbit_common

        {applications, [kernel,stdlib,compiler,crypto,public_key,sasl,ssl,syntax_tools,tools,xmerl,os_mon,runtime_tools,thoas,ranch,recon,credentials_obfuscation]},

I’ve dug in the processing of deps in systools_make.erl a little, but for the life of me cannot figure out why this is happening.

In poking around I modified systools_make.erl and removed the call to add_top_apps_to_uses/3 in function check_applications/1, and that allows a successful build of the release, but smlib and it’s applications are not started on boot (so obviously not a fix…)

I did generate a minimal app with amqp_client as its only dep, and that release built without any issues.

I then tried just adding our smlib app as the singular dep, and that built the release fine as well

I’ve also confirmed no other applications in the entire system other than smlib depend on amqp_client or rabbit_common.

The was an issue on rabbitmq GH filed with the same Circular dependency problem, which was unfortunately dismissed by rmq devs. Erlang AMQP 0-9-1 client releases on hex.pm have stopped at 4.0.3 · Issue #13379 · rabbitmq/rabbitmq-server · GitHub

Any help would be greatly appreciated.

2

Replying to myself here:

I managed to work out what was happening after extending systools_make.erl with some good-old-fashioned io:format debugs for when the rabbit_common app was being processed.

What was happening is rabbit_common depends on os_mon, and I had os_mon as an included_application in the main project smd, so systools was adding smd to the applications of rabbit_common, and this was the cause of the circular dependency.

I’m not sure if this should be filed as a bug.

TLDR: an app in included_applications is being used to affect application start order.

In my mind this is a bug, since included applications are not started at boot and the parent application does not require them to be running to boot.

Thoughts?

3

And replying to myself again for anyone who hits this in the future.

It’s not a bug, I was using the incorrect property.

What I should have been using is optional_applications, since my intent was to include another app in the release, but not have the app in the supervision tree.