user-callback error doesn't run on user-callback error

[protist]

# backintime --diagnostics
{
    "backintime": {
        "name": "Back In Time",
        "version": "1.4.3",
        "latest-config-version": 6,
        "local-config-file": "/root/.config/backintime/config",
        "local-config-file-found": true,
        "global-config-file": "/etc/backintime/config",
        "global-config-file-found": false,
        "started-from": "/usr/share/backintime/common",
        "running-as-root": true,
        "user-callback": "/root/.config/backintime/user-callback",
        "keyring-supported": false
    },
    "host-setup": {
        "platform": "Linux-6.9.9-arch1-1-x86_64-with-glibc2.39",
        "system": "Linux #1 SMP PREEMPT_DYNAMIC Fri, 12 Jul 2024 00:06:53 +0000",
        "OS": {
            "/etc/os-release": "Arch Linux",
            "/etc/arch-release": "\n"
        },
        "display-system": "($XDG_SESSION_TYPE not set)",
        "locale": "en_AU, UTF-8",
        "PATH": "/home/protist/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl",
        "RSYNC_OLD_ARGS": "(not set)",
        "RSYNC_PROTECT_ARGS": "(not set)"
    },
    "python-setup": {
        "python": "3.12.4 main Jun  7 2024 06:33:07 CPython GCC 14.1.1 20240522",
        "python-executable": "/usr/bin/python",
        "python-executable-symlink": true,
        "python-executable-resolved": "/usr/bin/python3.12",
        "sys.path": [
            "/usr/share/backintime/qt/plugins",
            "/usr/share/backintime/common/plugins",
            "/usr/share/backintime/plugins",
            "/usr/share/backintime/common",
            "/usr/lib/python312.zip",
            "/usr/lib/python3.12",
            "/usr/lib/python3.12/lib-dynload",
            "/usr/lib/python3.12/site-packages"
        ],
        "qt": "(Cannot import PyQt5)"
    },
    "external-programs": {
        "rsync": {
            "version": "3.3.0",
            "protocol": "31.0",
            "capabilities": {
                "file_bits": 64,
                "inum_bits": 64,
                "timestamp_bits": 64,
                "long_int_bits": 64,
                "socketpairs": true,
                "symlinks": true,
                "symtimes": true,
                "hardlinks": true,
                "hardlink_specials": true,
                "hardlink_symlinks": true,
                "IPv6": true,
                "atimes": true,
                "batchfiles": true,
                "inplace": true,
                "append": true,
                "ACLs": true,
                "xattrs": true,
                "secluded_args": "optional",
                "iconv": true,
                "prealloc": true,
                "stop_at": true,
                "crtimes": false
            },
            "optimizations": {
                "SIMD_roll": true,
                "asm_roll": false,
                "openssl_crypto": true,
                "asm_MD5": false
            },
            "checksum_list": [
                "xxh128",
                "xxh3",
                "xxh64",
                "md5",
                "md4",
                "sha1",
                "none"
            ],
            "compress_list": [
                "zstd",
                "lz4",
                "zlibx",
                "zlib",
                "none"
            ],
            "daemon_auth_list": [
                "sha512",
                "sha256",
                "sha1",
                "md5",
                "md4"
            ]
        },
        "ssh": "OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024",
        "sshfs": "3.7.3",
        "encfs": "(no encfs)",
        "shell": "/usr/bin/bash",
        "shell-version": "GNU bash, version 5.2.26(1)-release (x86_64-pc-linux-gnu)"
    }
}

Backintime installed from the AUR.

user-callback runs with $3=4 when there is an error. This generally functions fine. However, if the user-callback runs for a different reason (e.g. $3=1 Backup process begins), and the user-callback script subsequently fails, I would have expected the user-callback to be called again for this error (i.e. run again with $3=4). This does not occur.

FWIW @emtiu was not sure if this was a bug, so happy for this to be closed if this is the expected behaviour. My instinct was to put all the "error-fixing" stuff in the $3=4 section of the user-callback. I think this is neater, but it relies on this section being called when the user-callback fails. Alternatively (if this is not a bug, but expected behaviour), users would have to duplicate the "error-fixing" part themselves, by calling this function not only in $3=4, but also checking for errors in each other section, and calling that "error-fixing" function separately. One additional complication is if my $3=4 fails, then this could spawn an infinite loop. Perhaps that is dangerous enough to not fix this.