rabbitmqctl.bat exported definitions set virtual host default_queue_type to undefined

[iqesak]

Describe the bug

Using rabbitmqctl.bat to export definitions produce wrong metadata in vhosts array when using JSON format.
After trying to import previously exported definition JSON file, RabbitMQ fails to boot with exception repeatably.

ErlangOTP 26.2 (tested also in 25.3.2.28)
RabbitMQ 3.12.12

Reproduction steps

1. rabbitmqctl.bat export_definitions PreloadConfigFile.json --format json
2. put PreloadConfigFile.json into <management.load_definitions> folder
3. restart RabbitMQ service
4. RabbitMQ crash into exception during boot:
   ** Reason for termination ==
   ** {function_clause, [{rabbit_queue_type, discover, [<<"undefined">>], ...

if you open exported json file, you can find following section:
"vhosts": [{"limits":[],"metadata":{"default_queue_type":"undefined","description":"","tags":[]},"name":"/"}]

Expected behavior

section for vhosts in exported JSON file like:
"vhosts": [{"limits":[],"metadata":{"description":"","tags":[]},"name":"/"}]

without critical segment, which caused crash: "default_queue_type":"undefined"

Additional context

Exporting via management web page works fine without this issue.
Critical section looks like this: "vhosts": ["name":"/"}]
But I need to use a script.

[michaelklishin]

I'm afraid you haven't provided any evidence that the metadata was "wrong". No details on how the default queue type was set.

We can make the import part of the code ignore the default_queue_type when it is undefined but there is not enough information for us to reproduce this behavior and see what exactly leads to the difference between the HTTP API and rabbitmqctl. They both use the same internal API.

We do not guess in this community.

[iqesak]

I'm afraid, You didn't get the point, or didn't read carefully.
I said, if you do any export via cmd line and then do an import of same file via same rabbitmqctl.bat, RabbitMQ will not start anymore. Just try it, what else you need to describe?
Additionally I added rootcause.
But If you do not care, that one of the major feature export/import does not work, I can not help you anymore.
I did workaround in our SW already and thought, that community will appreciate it.
Looks like community/You are overloaded or exhausted, maybe disgusted from answering other offensive or to much assertive people, so you getting to be same.
Deleting an issue instead of marking it as duplicate or "not an issue" is from my point of view bold. This way you just loosing possibility to find a point in future to remind You... or someone.

[iqesak]

Taking back part with deleting an issue. Now I see, You moved to discussion... I am overloaded too... it is Friday :-)

[lukebakken]

I said, if you do any export via cmd line and then do an import of same file via same rabbitmqctl.bat, RabbitMQ will not start anymore. Just try it, what else you need to describe?

I can't reproduce what you report. Please see my comment.

[michaelklishin]

The only actionable item from this so far was moved to #10470.

[michaelklishin]

undefined is is the default value used, so it is accepted by the importing function.

Without a set of steps to reproduce and a more complete stack trace, I don't have any other hypothesis.

[lukebakken]

I am using Erlang 26.2.1 and RabbitMQ 3.12.12 on Windows 11 Pro.

@iqesak There must be some detail you're not telling us, because when I run rabbitmqctl.bat export_definitions, default_queue_type is not present in the JSON:

C:\Users\lbakken\issues\rabbitmq\rabbitmq-server\10469
> & "$env:RABBITMQ_SERVER\sbin\rabbitmqctl.bat" export_definitions rabbitmq-server-10469.json --format json; python -m json.tool .\rabbitmq-server-10469.json
Exporting definitions in JSON to a file at "rabbitmq-server-10469.json" ...
{
    "permissions": [
        {
            "configure": ".*",
            "read": ".*",
            "user": "guest",
            "vhost": "/",
            "write": ".*"
        }
    ],
    "bindings": [],
    "queues": [],
    "parameters": [],
    "policies": [],
    "rabbitmq_version": "3.12.12",
    "users": [
        {
            "hashing_algorithm": "rabbit_password_hashing_sha256",
            "limits": {},
            "name": "guest",
            "password_hash": "rqvX4MD2wwLr0unSgR7GCuYGuvygNiiP9RLFL69+hMTZ/SJZ",
            "tags": [
                "administrator"
            ]
        }
    ],
    "rabbit_version": "3.12.12",
    "vhosts": [
        {
            "limits": [],
            "metadata": {
                "description": "Default virtual host",
                "tags": []
            },
            "name": "/"
        }
    ],
    "exchanges": [],
    "global_parameters": [],
    "topic_permissions": []
}

[iqesak]

OK. This is relevant prove, I have something different in setup. Will try to reproduce it with striped users with passwords, because this is company's data, which I can not share. Will get back to you, when will have reproducible setup with some general data.

[michaelklishin]

You can remove all users and obfuscate virtual host, queue, exchange names. This is a virtual host setting, so that's what we care about the most.

Thank you for taking the time to reproduce.

[iqesak]

So I did some tests and I got the point, when "default_queue_type": "undefined" occurs in exported definition.
First I tried to remove all used plugins, but no difference.
So I subscribed one client to simple direct AMQP exchange and then published using second client a message to it.
Either subscribe or publish caused, that exported definition contains "default_queue_type": "undefined".
It persist there even after restart of RabbitMQ. Only rabbitmqctl force_reset removes it.

Attached simple PreloadConfig.json with guest user, and External.PUB.DisplayMessage, which I tested for publishing.
PreloadConfig.json

A Payload was JSON string with data, but it does not matter. I used TLS connected clients using certificates, but I think this also does not matter. You just need to send one message. Let me know, if you could reproduce, or You need more info.

Exported vhosts section before sending first message:
"vhosts": [
{
"limits": [],
"metadata": {
"description": "",
"tags": []
},
"name": "/"
}

Exported vhosts section after sending first message (import of this will cause exception in RabbitMQ boot):
"vhosts": [
{
"limits": [],
"metadata": {
"description": "",
"tags": [],
"default_queue_type": "undefined"
},
"name": "/"
}

[lukebakken]

So I subscribed one client to simple direct AMQP exchange and then published using second client a message to it.
Either subscribe or publish caused, that exported definition contains "default_queue_type": "undefined".

This is very vague information that we can't use. We need to know the following:

• What client library is being used?
• Can you share the code for this test?

[michaelklishin]

Neither subscribe nor publish can have an effect on this virtual host setting. This is set when a virtual host is created, or when its metadata is explicitly updated (using CLI tools or the HTTP API).

Something in the frameworks(s) you use may be setting up the virtual host lazily, that is, right before you publish or consume for the first time.

See internal events that are emitted during the test, server logs, and if none of those reveal anything, take a traffic capture (that will include HTTP API traffic to the node, which can be logged if you opt in).

[iqesak]

I will try to trace internal events too. Anyway we planning to use internal events to watch connection state of partners. So I can play with it little more. Take in consideration, that I am dumb tester, I do not see inside RabbitMQ or Erlang. And those are the best. :-) They drive you crazy, but finally you take your head into hands and say: Yes, how I can not see it before. I know that feeling, developing more then 20 years...

[michaelklishin]

In the provided definition file, you can see that the default_queue_type field is not set:

  "vhosts": [
    {
      "limits": [],
      "metadata": {
        "description": "",
        "tags": []
      },
      "name": "/"
    }
  ],

So it makes sense for it to be returned as undefined in certain contexts.

[iqesak]

I understand, that it makes sense in certain conditions. Then, let us take it from other side: Make import of such a definition bulletproof to not crash RabbitMQ on the boot with such a definition.

[lukebakken]

@iqesak I still can't reproduce this issue. We will need exact steps to reproduce.

[iqesak]

I will be back with reproduction steps, but now I am busy with other issues on our current project. give me some days.