Misleading Shovel URI Example for fail_if_no_peer_cert option

[robo-w]

Describe the bug

The last URI example for the dynamic shovel configuration shows the URI parameter fail_if_no_peer_cert=true set:

Since the upgrade to RabbitMQ 3.13.2 with Erlang 26.2.5 this option produces following error when set:

2024-09-05 13:55:33.235000+02:00 [error] <0.1524.0> Shovel 'some-example-shovel' failed to connect (URI: amqps://test-host.local:5671/%2F): {option,server_only,fail_if_no_peer_cert}

On a RabbitMQ 3.11.x installation with Erlang 25.2 the URI like in the example worked fine, but since the upgrade it works only if the option is removed.

From the documentation of the parameter/config option it also does not really make sense to set it on client side (shovel URI). I think removing the parameter from the example is sufficient.

Reproduction steps

1. Configure a shovel with a source URI based on the example URI amqps://server-name?cacertfile=/path/to/cacert.pem&certfile=/path/to/cert.pem&keyfile=/path/to/key.pem&verify=verify_peer&fail_if_no_peer_cert=true&auth_mechanism=external. The URI must include the parameter fail_if_no_peer_cert=true.
2. Shovel does not start with the error {option,server_only,fail_if_no_peer_cert} - not OK

RabbitMQ version: 3.13.2 Erlang version: 26.2.5

Expected behavior

The listed example URIs of the shovel plugin should work.

Additional context

No response

[robo-w]

I looked into the code where to fix the examples: apparently it was already fixed in #11319, but not released in a version yet.

[michaelklishin]

There were several 3.13.x releases since #11319.

[michaelklishin]

The key commit in #11319 is 5b977562a8bef12e4de5ba4f374af48c54bab7cb.

git cherry-pick -x 5b977562a8bef12e4de5ba4f374af48c54bab7cb -m 1

suggests it has been backported. 3.13.2 is five, and soon enough will be six, patch releases behind. @robo-w consider upgrading to the latest patch release before you file issues.