"Unable to complete update, please contact Pi-hole Support"

[FL-TOAST]

Expected Behaviour:

PiHole just works reliably -- as always

Actual Behaviour:

"Unable to complete update, please contact Pi-hole Support"

Debug Token:

TWO systems with same result:
System 1: https://tricorder.pi-hole.net/uQAGpunB/
System 2: https://tricorder.pi-hole.net/UyaOaDKD/

Note/add: Both systems appear to be operating OK and running with the current versions -- in spite of the warnings received.

[Bucking_Horn]

You're probably correct about your Pi-holes being operational despite that error.

Your UyaOaDKD suggests connectvity issues, but those could probably be attributed to the fact that your ran that debug log directly after a Pi-hole restart/reboot:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve www.d3o6x6wcpxd286.cloudfront.net on lo (127.0.0.1)
[✗] Failed to resolve www.d3o6x6wcpxd286.cloudfront.net on eth0 (192.168.99.10)
[✓] doubleclick.com is 172.253.62.102 via a remote, public DNS server (8.8.8.8)

*** [ INITIALIZING ]
[i] 2022-11-16:10:15:10 debug log has been initialized.
[i] System has been running for 0 days, 0 hours, 1 minutes

*** [ DIAGNOSING ]: Pi-hole-FTL full status
   ● pihole-FTL.service - LSB: pihole-FTL daemon
   Loaded: loaded (/etc/init.d/pihole-FTL; generated)
   Active: activating (start) since Wed 2022-11-16 10:13:33 EST; 2min 0s ago

If both Pi-holes respond to DNS requests, I'd suspect a glitch in the update script rather than an issue with Pi-hole.

Probably unrelated, your debug logs show some peculiarities (click for details).

It would seem you are running your two Pi-holes on two different subnets:
192.168.50.0/24 with Pi-hole at 192.168.50.10 (uQAGpunB)
192.168.99.0/24 with Pi-hole at 192.168.99.10 (UyaOaDKD)

For both subnets, the respective DNS server distributes your Pi-hole as well as another DNS server:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 300 bytes from eth0:192.168.50.2
     Offered IP address: 192.168.50.159
     DHCP options:
      Message type: DHCPOFFER (2)
      netmask: 255.255.255.0
      router: 192.168.50.2
      dns-server: 192.168.99.10
      dns-server: 192.168.50.10
      --- end of options ---

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers

   * Received 300 bytes from eth0:192.168.99.2
     Offered IP address: 192.168.99.185
     DHCP options:
      Message type: DHCPOFFER (2)
      netmask: 255.255.255.0
      router: 192.168.99.2
      dns-server: 192.168.99.10
      dns-server: 192.168.25.10
      --- end of options ---

Note that as your subnets are /24 (netmask 255.255.255.0), a respective DNS server
from another subnet would not be reachable, unless your router would provide inter-subnet routing.
Also note that for the 192.168.99.0/24 network, your second DHCP server is distributing 192.168.25.10 as DNS server, which belongs to neither of your Pi-holes.

And finally, your debug logs seem some 6 hours apart:

*** [ INITIALIZING ]
[i] 2022-11-16 15:14:01 debug log has been initialized

*** [ INITIALIZING ]
[i] 2022-11-16 10:15:10 debug log has been initialized.

This looks unusual for a joint report, but may well have been accurate.
If it's not, you may want to check your local times and time zone configurations.

[FL-TOAST]

Good observation re the subnetting. In actuality there are three PiHoles on three different subnets at different locations "joined" together via Peplink SpeedFusion tunnels. Inter-VLAN routing and OSPF allows one to be accessible from the others. And, one of the system clocks should be set to UTC and the others are local time -- but I'll check that.

Thanks for taking a look and your well-taken observations! :<)