Stubby spams log with "Could not schedule query" when internet goes down

Installing and Using OpenWrt
1

I've had stubby installed for almost a year on openwrt and haven't run into issues until now. This might be because it's been that long since my wan link has been down, either way my internet went off the other day and when I checked my openwrt log I saw thousands of these messages from stubby:

Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports

Not only that but the messages were repeating almost every second, was literally the only thing in my entire log.

I suspected it was happening because my internet went down, so to test it I waited for the internet to come back on and opened my syslog, after that I unplugged my modem and instantly got the stubby messages.

If it's failing when there's no connection I thought it must be because there's a setting somewhere that controls the number of failed retry attempts, so I checked the documentation and there was one, at least tls_connection_retries looked pretty close. I also found tls_backoff_time & timeout which I thought might help and so I updated my stubby config to this:

config stubby 'global'
       option manual '0'
       option trigger 'wan'
       list dns_transport 'GETDNS_TRANSPORT_TLS'
       option tls_authentication '1'
       option tls_query_padding_blocksize '128'
       option appdata_dir '/var/lib/stubby'
       option edns_client_subnet_private '1'
       option idle_timeout '10000'
       option tls_connection_retries '2'
       option tls_backoff_time '3600'
       option timeout '5000'
       option round_robin_upstreams '1'
       list listen_address '127.0.0.1@5453'
       list listen_address '0::1@5453'

config resolver
       option address '2606:4700:4700::1111'
       option tls_auth_name 'cloudflare-dns.com'

config resolver
       option address '2606:4700:4700::1001'
       option tls_auth_name 'cloudflare-dns.com'

config resolver
       option address '1.1.1.1'
       option tls_auth_name 'cloudflare-dns.com'

config resolver
       option address '1.0.0.1'
       option tls_auth_name 'cloudflare-dns.com'

And then repeated my test by unplugging my modem, but the same thing is still happening. Has anyone else had a similar issue or have any ideas?

The only other thing I've found that's similar is this thread: https://github.com/getdnsapi/stubby/issues/133 but it was marked as solved when the OP set stubby to only turn on after their wan is connected. I wouldn't really consider this a solution though, because if at any point your wan goes down stubby will completely spam your log and seemingly send endless requests to a server it can't reach.