maestral: `v1_retired` API error

I appreciate that this error is not directly caused by Maestral, and you’re understandably tired of hearing about it.

But Maestral’s poor handling of this error is making it almost unusable as a client recently because it’s now both annoying (by presenting a dialog to the user while they’re working in other apps) and unreliable (by pausing sync upon the first API failure and never resuming without user intervention, rather than silently retrying after a short delay and only alerting the user if it fails repeatedly over a long timespan).

And the particular error message (“API retired”) erroneously suggests to users that Maestral is old and unmaintained, and they should probably look for another app.

I bet a lot of people (most of whom will never see your explanation here) uninstalled Maestral over the past week. I’m coming close. And it’s not your fault — but this is very much your problem, and waiting for Dropbox to fix a low-priority API as you bleed users is unwise.

Quick update: The problem still persists server-side but I’ve tried to mitigate it now by retrying the failing refresh token calls up to five times. Since “only” about 10% of calls are failing, and rarely consecutively, this retry logic should fix the symptoms, however not the cause.

@Roy-Orbison as someone who deals regularly with dependencies breaking underneath me and (paying) customer fallout, the reality is that a client application is still to a degree responsible for what its dependencies are doing. Assigning fault at Dropbox doesn’t discharge Maestral of having the bug. This brings to light several courses of action that could be taken:

• Better error messaging, especially indicating what operations might have failed, if there is data loss, and a course of action to take
• Automatic restarting or recovery so that a quit/relaunch isn’t required (multiple times a day, today)
• Possibly using other API calls or workarounds to achieve the same result

Regardless, I mainly wanted to report that this has gotten significantly worse today for whatever reason! I’m happy to send any config info/logs if that can help.

I’ve reported the issue to Dropbox and they are looking into it. It appears that something similar occurred previously already.

@Roy-Orbison, I appreciate the intention behind closing this issue. Unfortunately, it just results in new issues being created instead. I’ll reopen this as a tracking bug and to report any news to people affected, once there is any.

Getting this a lot, just like everyone else. Unpausing just brings it back minutes later.

My first thought, as mentioned by other commenters, was that Maestrial was relying on an API that Dropbox has retired, and that’s the end of the client. My first instinct was to visit Maestrial website or this github’s README for an announcement (or just an acknowledgement of this error – it likely affects majority of users).

I would encourage pushing a hotfix to at least mute this particular error and implement a temporary workaround.

To close the loop on this, the issue has finally been fixed on the Dropbox side. It took them some time…

Closing this as it’s just “me too” comments now. @samschott has already reported it, and it’s not this program’s fault.

Just got this too, fwiw.

I’m using this in a every-5-minutes-cronjob as a temporary workaround (resuming works for me, but start/stop is of course also possible this way):

maestral status | grep -e '^Status.*Paused' && maestral resume

I decided to make the switch to Maestral yesterday and installed v1.6.2. Unfortunate timing.

I know we want to keep the “me too” posts to a minimum, but the behavior I’m seeing on this first-time installation may be of interest. Of the 17.86GB in my Dropbox account, Maestral was able to download 16.56GB after installation without issue before the following error occurred:

Note the “Path: rev:” info which I have not seen in other screenshots. This remains consistent each time the error occurs.

If I try “Resume Syncing”, the error is displayed again within a few seconds. This behavior continues regardless of whether I restart the app or the computer, which is unlike other commenters here who note that Maestral works properly for an hour or so after resuming. This is all happening on an 2020 MacBook Air (M1) running macOS 12.4. No sync errors reported.

The interesting part (to me) is the fact that Maestral was able to download most of my files before displaying the error, but now it appears completely stuck. Maybe I just got lucky and had a working window after my initial install, but I would have assumed the API response would be somewhat consistent.

I woke up to one of these and I just got another one a minute ago. I’m not saying you need to flag it just yet but I wanted to provide the data point that I’ve seen this error twice now.

Got this error three times today. Resume syncing fixes it for a few hours. @samschott referring to your comment did Dropbox actually fix this on their side? Is it possible to integrate a workaround like automatically resuming on this error?

Issue is still occurring for me. Happened 2 minutes ago (2022-05-26 20:32NZST). macOS Monterey, GUI 1.6.2, daemon 1.6.2.

It seems possible that a bug that was ‘fixed’ in 2018 might be reintroduced on the Dropbox API by Dropbox.

A more recent issue is opened there. I think it might make sense to place further encouragements/upvotes/information there (if one feels that it is needed/effective).

I think the above info is what Sam (not tagging him), has already wrote.

Based of @maiksd comment: For those using the MacOS GUI (like myself) you can paste this in terminal and keep it running/open. Please note that the GUI icon might stay on paused state (but it is syncing).

#!/bin/bash
while :
do
  if (/Applications/Maestral.app/Contents/MacOS/maestral-cli status | grep -e '^Status.*Paused') &> /dev/null
  then
	echo 'Resuming sync, keep watching'
	/Applications/Maestral.app/Contents/MacOS/maestral-cli resume
  fi
  sleep 5  # seconds interval
done

Instead of pasting one could create a cron (*but in later MacOS you need to grant some extra permissions so be advised).

@samschott My understanding is that closing an issue doesn’t prevent comments, it just lets people know that there’s nothing you can solve because it’s not Maestral’s fault.

For whatever this is worth, this has happened twice for me today as well. GUI 1.6.2, daemon 1.6.2 Doesn’t seem to be causing problems, but seemed noteworthy.

Agreed with those stating this is “workaroundable”. If I knew python, I would attempt a patch. I would consider such a patch temporary, and flag it for removal once the API call is known fixed.

Something like: catch this specific exception, start a thread. The thread waits a few minutes, and then tries restarting sync. If sync works the thread terminates, otherwise it repeats waiting again.

Zero issues after update couple days ago. 👍

Yeah after recommending this app to a ton of friends, this is a big deal for me Ive had a few cases now (in important situations) where i’m missing files and it turns out my production machine hasn’t been syncing …the second the app is anything BUT 100% reliable, it’s 0% reliable.

I know the me-too’s are annoying but since not many people have posted in a week I just wanted to let people know it’s still happening. I just installed Maestral on a new Mac and I’m hitting this about once an hour. Resuming works fine but I have to resume every time.

Just wanted to re-up a note by ricir above, which is that folks should absolutely be posting on the Dropbox Issue <-- We know Sam is on this as best he can be, so I think this thread is the best place to make noise and get this solved!

Originally downloaded this app as the Mac native alternative to Dropbox which required Rosetta. Looks like Dropbox has updated their Mac version to be native on M1 now so no real reason to keep it, especially if this bug persists. Has anyone switched between them? Anything to be aware of when I switch back?

I have tried Dropbox native client again. Even with Apple Silicon support it is a resource hog compared to Maestral. Even without syncing Dropbox keeps CPU % usage very high. I might say it is worse than on Intel Macs. I noticed effects on battery life as well, even on MacBookPro M1. Also Maestral’s .mignore is ingenious.

If this syncing issue continues I will probably move everything to OneDrive. 🤷‍♂️

@tempelmann Works for me, too! Should this maybe be submitted as a PR to the official Dropbox Python library?

So I did some testing and found a possible work-around, just as I suggested above:

1. I installed Maestral using the given python + pip commands. This installs the source code /Users/tempi/Library/Python/3.8/lib/python/site-packages/dropbox/dropbox_client.py

2. I then edited the dropbox_client.py, inserting at line 626 the following 3 lines (i.e. before the else:and raise lines):

                elif res.json()['error'] == 'v1_retired':
                	# (TT 02Jun22) ignore, see https://github.com/samschott/maestral/issues/683
                	return
                else:
                    raise BadInputError(request_id, res.text)

With this, the v1_retired gets simply ignored, but the synchronization keeps working (while, at the same time, the same error on another computer led to pausing sync again).

Could someone else please try this and report whether it works for them, too?

Actually there are a least two good reasons for maestral, as Dropbox dropped A LOT of functionality from their native client.

• My $home is on NFS. Dropbox removed support for Dropbox folders on network file systems. Not even properly working anymore if there is a softlink pointing to folder outside a network file system so all extended attributes would be available.

• Dropbox introduced a 'number of connected device limit. I was well over that limit and when I once updated a machine, on which the native dropbox client was happily working, dropbox suddenly claimed this is a new machine and locked my client out.

This has been popping up for me for days (definitely more than a week) and the frequency has increased a lot recently; I now get it multiple times a day and have to manually resume syncing every single time.

It breaks my heart because I absolutely hate the official Dropbox app and Maestral has been a godsend since I’ve heard about it and started using it in October 2021, but currently it’s:

• Pushing loyal Maestral users dangerously close to uninstalling and either switching back to the official app or seeking another alternative, since it’s now so unreliable and so very annoying.
• Making it impossible to recommend to other people.
• Driving newcomers who heard good things about it away in a matter of days, if not hours. Reliability is key.

And the sad reality is it doesn’t matter if it’s a problem on Dropbox’s side — you’re paying for it. Maestral should handle this error better until it’s resolved by Dropbox.

macOS 12.4 (21F79) — Maestral GUI v1.6.2, daemon v1.6.2

have this issue as well.

This has been happening to me on an M1 Mac Mini MacOS 12.4 for a few weeks. Still happening now, no sync possible.

Can confirm this is still happening. Appreciate the follow-up from Dropbox, hopefully this will be resolved soon.

I’m having this issue as well, and the frequency has increased significantly in the past few days.

I’ve been having this issue occasionally, but today has been occurring very frequently, just a few minutes apart, pausing the sync