Inconsistent net_ticktime reported by rabbitmqctl report vs rabbitmqctl status on Windows

[Mistra]

Describe the bug

Hello. I’m aware of the Windows-specific requirement to set net_ticktime via an environment variable rather than just in rabbitmq.conf.

However, I’ve noticed an inconsistency in the output of the following commands when I only set net_ticktime = 120 in rabbitmq.conf (without defining it as an environment variable):

rabbitmqctl.bat report | findstr "net_ticktime"

Outputs:

{net_ticktime,120},

Whereas:

rabbitmqctl.bat status | findstr "net_ticktime"

Returns:

Cluster heartbeat timeout (net_ticktime): 60

This is confusing, as the values should match.

Reproduction steps

1. Install Rabbitmq (tested with 4.0.7) in Windows Server 2022
2. Inside rabbitmq.conf set net_ticktime = 120
3. Start Rabbitmq
4. Lauch rabbitmqctl.bat report | findstr "net_ticktime" -> 120
5. Lauch rabbitmqctl status | findstr "net_ticktime" -> 60

Expected behavior

If net_ticktime is ignored from rabbitmq.conf on Windows (as documented), I would expect both commands to report the default value (60). Alternatively, if rabbitmqctl.bat report shows 120, it implies that the config was parsed — which contradicts the behavior of rabbitmqctl status.

Is this a known issue? Shouldn’t both outputs reflect the same effective setting?

Additional context

No response

[michaelklishin]

rabbitmq-diagnostics status and rabbitmq-diagnostics report (that includes the same output as status) display the application environment. Neither has no Windows-specific awareness.

net_ticktime cannot be set via rabbitmq.conf for the Windows service only. If you run RabbitMQ on Windows any other way, it should work as it does everywhere else.

You'll have to deal with it, our CLI tools are not aware of how the node was started and making them aware sounds like a waste of time of our small team.