ERROR: WAL synchronisation for server XY failed with: Expected 2 arguments, got 1

[eoener-tpgroup]

Hey all,

We are using a passive barman node (barman 3.9.0) to sync created backups and wal files from primary barman node.
The retention policy on the primary barman is configured for 3 days and on the passive node for 31 days.

Unfortunately we get following error inside of barman.log

2024-02-29 17:55:43,025 [3868498] barman.cli DEBUG: Initialised Barman version 3.9.0 (config: /srv/barman-archive/.barman.conf, args: {'color': 'auto', 'quiet': False, 'debug': False, 'format': 'console', 'command': 'sync-wals', 'log_level': 'DEBUG', 'server_name': 'XY', 'func': <function sync_wals at 0x789c5fb81790>})
2024-02-29 17:55:45,341 [3868498] barman.server DEBUG: Retention policy for server XY: REDUNDANCY 31
2024-02-29 17:55:45,341 [3868498] barman.server DEBUG: WAL retention policy for server XY: MAIN
2024-02-29 17:55:45,341 [3868498] barman.server DEBUG: sync_wals(XY)
2024-02-29 17:55:45,353 [3868498] barman.server ERROR: WAL synchronisation for server XY failed with: Expected 2 arguments, got 1

This error occures, when the barman cron starts or when you try to sync the wal files manually
# barman sync-wals XY

Somehow this error also causes, that no new backups from primary database are syncronized to the passive node, at least, thats what I am thinking.
Even syncronizing the latest backup to the passive node, doesn't fix the issue with the wals.

Also I tried to understand the sync_wals(self) method inside server.py, but couldn't understand, where it expects 2 arguments.
Unfortunately a search with google didn't give any usable result in this case.

Thank you!

[gcalacoci]

Hi,
This is strange, could you run the barman diagnose and post the output here, after removing any sensitive information from the output?

Thanks!

[eoener-tpgroup]

Hey,
thanks for the fast reply. I upload the output of barman diagnose to this issue. I removed all sensitive information and all other servers, that are configured. I only left one server, which has also the issue (unfortunately multiple servers experience the same issue, not all though).
barman_diagnose.txt

[eoener-tpgroup]

After downgrading barman 3.9.0 to 3.6.0 this issue was not present anymore, so I think, this is a issue within the version 3.9.0 (maybe also in 3.10.0)