Release: 2.1.0.107 (Canary) 2025-01-17

2.1.0.107_canary_2025-01-17

This release is a canary release intended to be used for testing.

Note that this build has a redesigned restore flow
Should issues arise, the previous restore engine can be enabled with --restore-legacy=true.

This release contains a substantially updated version of the new UI.
In the url, change ngax to ngclient to try the new UI.

Detailed list of changes:

  • Avoid optimize after vacuum
  • Prevent inifinite shutdown loop
  • Fixed a recreate database issue
  • Added a warning in the UI if the volume size is excessive
  • Fixed an issue with AWS S3 permission check
  • Prevent a termination error caused by unused transactions
  • Updated B2 backend to use HttpClient
  • Changed timeouts for WebDAV
  • Updated new UI (ngclient)
1 Like

I don’t think it’s a new bug in this Canary, but a new bug in 2.1. To continue with an old question:

2.0.8.1 handles this more predictably and nicely. If you log out of a tab, it pops up a box informing

Trying to do things (seems very broad) in another tab gets the same thing. OK gets login screen.
One questionable behavior is after doing login, the OK to above box in another tab runs similarly despite access being open if you edit page URL to not have the login.html component any more. Consistency is often good, but convenience (just let tab in if user did login elsewhere) is nice too.

Now let’s try in 2.1.0.107. I think the 2.1.0.2 behavior is similar, although not completely identical.
Open two tabs to home page, refresh to remove the cached leftovers, Log out on one of the tabs. get a login.html screen. Go to the other tab and try to do something, e.g. click About, which goes “Loading” forever (with a message to TrayIcon console that most probably didn’t set up to check).

A job Run is ignored, and a job Edit gets

OK does nothing visible. Having learned that refresh often helps the flaky GUI, try that and get

and the Log in button at least leads to the login.html screen and access again, but it’s kind of ugly.

Ignoring things that seem like more clearcut bugs (like buttons that do nothing), what are planned interactions between Log out on a tab, and behavior on another tab in same or different browser?

The way it should work is that the refresh token is stored as a cookie in the browser, shared between tabs. When you log out, it revokes the refresh token, so all tabs are logged out.
However, each tab that is logged in has an access token that expires after 15 minutes, so you may be logged in for a while, but reloading the page will fail.

I think there is some quirky behavior around the detection of a login fail that was more smooth in 2.0.8.1, because it was a bit simpler.

Possibly there are other GUI actions that act on local data, so can be continued indefinitely?

2.0.8.1 seemed more prone to notice. I can’t say I’ve characterized the new scheme heavily.

One reason I called for a refresh before testing was to clear out information from JavaScript.

Just reminding of remaining quirky behavior, which fortunately not many others are noticing…

[MAC OS Sequoia, Chrome browser, Duplicati 2.1.0.107]

The first few tries to get the “ngclient” UI just gave me a blank (white) screen, until I logged out and in again on the “ngax” client, then “ngclient” prompted for my password.

I got a few alert popups opening “ngclient”, but the only one that persists is:

“Http failure response for
*** http://localhost:8200/api/v1/progressstate: *** (asterisks added)
404 not found”

Doesn’t seem to be a problem for the UI, though.

Thankz… Steve

While I was typing the above Reply, the “ngclient” UI logged me out and prompted for my UI password. When I logged in again, I got the “progressstate” error alert again, as well as:

Http failure response for
*** http://localhost:8200/api/v1/serverstate? *** (asterisks added) lastEventId=11&longpoll=true&duration=299s:
401 Unauthorized

Thanks again… Steve

update: “ngclient” UI again logged me out (overnight), and prompted for my UI password… this may be an issue? (btw… I’m using the “dark” background - looks great!)

CLI AutoUpdater seems broken in, e.g. 2.1.0.107, 2.1.0.106, 2.1.0.102:

C:\Duplicati\duplicati-2.1.0.107_canary_2025-01-17-win-x64-gui>Duplicati.CommandLine.AutoUpdater check
Error detected: System.NullReferenceException: Object reference not set to an instance of an object.
   at Duplicati.Library.Utility.HttpClientExtensions.DownloadFile(HttpClient client, HttpRequestMessage request, String filename, Action`1 progressReportingAction, CancellationToken cancellationToken)
   at Duplicati.Library.AutoUpdater.UpdaterManager.CheckForUpdate(ReleaseType channel)
Error detected: System.NullReferenceException: Object reference not set to an instance of an object.
   at Duplicati.Library.Utility.HttpClientExtensions.DownloadFile(HttpClient client, HttpRequestMessage request, String filename, Action`1 progressReportingAction, CancellationToken cancellationToken)
   at Duplicati.Library.AutoUpdater.UpdaterManager.CheckForUpdate(ReleaseType channel)
No updates found

EDIT:

Testing versions, problem seems to have begun in v2.0.9.108_canary_2024-10-03

Thanks for that. I will be testing various behavior scenarios with ngclient soon, and my focus will be on making this experience smoother.

That is a known issue. It was designed a bit different originally, so it only stays logged in for 15 minutes.
It has been fixed 2 days ago, and will be part of the next canary build.

That is an API design issue. It returns 404 because there is no active process.
We have some plans to update the API to be more modern, but that will break some things.

Perhaps we should add a filter to this message to prevent it cluttering the view until the API is fixed.

Hmm, I guess not a lot of people use that. I have registed an issue for the broken autoupdater.

Thanks for the reply. One more nit: when I refresh the “ngclient” screen in dark mode, it reverts to light mode, so I have to click the moon icon again.

Keep up the good work!

I just tried this with the latest developer version and I do not have the problem, so I think it is fixed :crossed_fingers: .
(Tried with Safari and Chrome)