Definitions import of bad json goes unnoticed

[lukebakken]

To reproduce:

• Save this file as definitions-bad.json: definitions-bad.json.txt
• Enable the management plugin
• Use the following configuration line in rabbitmq.conf:

  management.load_definitions = /path/to/definitions-bad.json
  

• Start RabbitMQ

Observed: RabbitMQ starts fine, nothing is logged to indicate the invalid JSON in that file.

Expected: log message(s) indicating bad JSON

Loading invalid definitions without using rabbitmq_management in master prevents RabbitMQ from starting.

[jms1voalte]

To clarify, this happened using the 3.8.2-1.el7 RPM on CentOS 7.

Also I noticed that normally there's a specific sequence of log messages produced during the import:

2020-02-18 18:05:22.532 [info] <0.339.0> Asked to import definitions. Acting user: rmq-internal
2020-02-18 18:05:22.533 [info] <0.339.0> Importing users...
2020-02-18 18:05:22.533 [info] <0.339.0> Importing vhosts...
2020-02-18 18:05:22.533 [info] <0.339.0> Importing user permissions...
2020-02-18 18:05:22.533 [info] <0.339.0> Importing topic permissions...
2020-02-18 18:05:22.533 [info] <0.339.0> Importing parameters...
2020-02-18 18:05:22.586 [info] <0.339.0> Importing global parameters...
2020-02-18 18:05:22.586 [info] <0.339.0> Importing policies...
2020-02-18 18:05:22.626 [info] <0.339.0> Importing queues...
2020-02-18 18:05:22.652 [info] <0.339.0> Importing exchanges...
2020-02-18 18:05:22.653 [info] <0.339.0> Importing bindings...
2020-02-18 18:05:22.676 [info] <0.339.0> Running boot step empty_db_check defined by app rabbit

When the file is bad, this list of log messages stops but the node keeps starting up:

2020-02-21 17:41:28.630 [info] <0.26638.7> Asked to import definitions. Acting user: rmq-internal
2020-02-21 17:41:28.630 [info] <0.26638.7> Importing users...
2020-02-21 17:41:28.630 [info] <0.26638.7> Importing vhosts...
2020-02-21 17:41:28.631 [info] <0.26638.7> Running boot step empty_db_check defined by app rabbit

[mjattie]

encountered this today as well, had json that worked fine in the 3.10 release, but because the json serializer changed in 3.11, the import failed suddenly. There was a comma at the end of a value that shouldn't be there... Would be nice to have a log message!