"Request Queue is full" browser message

I opened (and logged into) my unRAID Docker Duplicati (2.0.3.12) instance today and it seemed to have lost all my jobs.

I assumed the Docker had restarted for some reason (which - at least for me - is known to cause this issue) so went to Help -> About to check the version number.

The page came up with “version unknown” (or something like that) then popped up the "not connected message with the reconnect countdown timer. Attempted reconnects just resulted in the “connection lost” message.

I got busy with other things and left it on that message (with the countdown retry) and at some point it changed to giving me a “Request Queue is full” message in an empty web page.

Manually refreshing the page now ONLY shows me the queue full message even when connecting form another browser session. My GUESS is the daemon is running (sort of) and the “accept requests from the web UI” queue has gotten full because the “hey, Duplicati please do this requested action” process has gotten stuck and is no longer responding.

A restart of the Docker container seems to have resolved the issue, but I thought I’d check if anybody else has run into this message.

There were a couple of reports in 2015, one a mystery and one seemingly caused by a weird configuration.

Source of the message is possibly here.

Just an FYI - had the same thing (walked away from “connection to the server lost” countdown message) happen with 2.0.4.10 canary.

I’m not restarting the Docker container yet as I believe it’s busy with a database Recreate test. (At least I hope so, based on the CPU usage.) :slight_smile:

Note that I’m getting back a “503 ServiceUnavailable” response. Why doesn’t the UI detect that and show a different message (and stop the countdown)?

Just for the record, it happened again. Was connecting over a VPN (not sure why that would be an issue) and started getting odd UI experience (empty select lists, all my jobs disappearing, etc.) then the “Request Queue is full” message.

Restarting Duplicati (in this case the Docker container) resolved the issue.

Note that despite the full queue message in the UI, the server still performed scheduled backups - so that’s good. :slight_smile: