v1_retired API error

[Roy-Orbison]

Describe the bug
An alert dialogue from Maestral and a system toast notification both appeared with the same {"error": "v1_retired"} message, then Maestral's status icon showed as paused (⏸).

To Reproduce
No specific actions, Maestral was running in the background. I had not made any recent changes within the synced root dir.

Expected behaviour
Use the current API, I guess.

System:

• Maestral version: 1.6.2
• Python version: 3.9.7
• OS: Kubuntu
• Desktop environment: KDE
• PyQt version (for Linux GUI): 5.15.4

Additional context
Log:

2022-05-24 11:17:53 manager ERROR: Bad input to API call
Traceback (most recent call last):
  File "/home/roy/.local/lib/python3.9/site-packages/maestral/errorhandling.py", line 94, in convert_api_errors
    yield
  File "/home/roy/.local/lib/python3.9/site-packages/maestral/client.py", line 1333, in wait_for_remote_changes
    res = self.dbx.files_list_folder_longpoll(last_cursor, timeout=timeout)
  File "/home/roy/.local/lib/python3.9/site-packages/dropbox/base.py", line 2282, in files_list_folder_longpoll
    r = self.request(
  File "/home/roy/.local/lib/python3.9/site-packages/dropbox/dropbox_client.py", line 301, in request
    self.check_and_refresh_access_token()
  File "/home/roy/.local/lib/python3.9/site-packages/dropbox/dropbox_client.py", line 369, in check_and_refresh_access_token
    self.refresh_access_token(scope=self._scope)
  File "/home/roy/.local/lib/python3.9/site-packages/dropbox/dropbox_client.py", line 403, in refresh_access_token
    self.raise_dropbox_error_for_resp(res)
  File "/home/roy/.local/lib/python3.9/site-packages/dropbox/dropbox_client.py", line 627, in raise_dropbox_error_for_resp
    raise BadInputError(request_id, res.text)
dropbox.exceptions.BadInputError: BadInputError('<REDACTED 32-char hex>', '{"error": "v1_retired"}')

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/roy/.local/lib/python3.9/site-packages/maestral/manager.py", line 843, in _handle_sync_thread_errors
    yield
  File "/home/roy/.local/lib/python3.9/site-packages/maestral/manager.py", line 670, in download_worker
    has_changes = self.sync.wait_for_remote_changes(
  File "/home/roy/.local/lib/python3.9/site-packages/maestral/sync.py", line 2854, in wait_for_remote_changes
    has_changes = client.wait_for_remote_changes(last_cursor, timeout=timeout)
  File "/home/roy/.local/lib/python3.9/site-packages/maestral/client.py", line 1333, in wait_for_remote_changes
    res = self.dbx.files_list_folder_longpoll(last_cursor, timeout=timeout)
  File "/usr/lib/python3.9/contextlib.py", line 137, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/home/roy/.local/lib/python3.9/site-packages/maestral/errorhandling.py", line 96, in convert_api_errors
    raise dropbox_to_maestral_error(exc, dbx_path, local_path)
maestral.exceptions.BadInputError: Bad input to API call. {"error": "v1_retired"}
2022-05-24 11:17:53 manager INFO: Shutting down threads...
2022-05-24 11:17:53 sync INFO: Sync aborted
2022-05-24 11:17:53 manager INFO: Paused
2022-05-24 11:19:43 sync INFO: Sync aborted
2022-05-24 11:19:43 manager INFO: Paused

[To1ne]

I'm having the same issue. But the dropbox API v1 is retired since September 2017 already, see https://dropbox.tech/developers/api-v1-deprecated, so I doubt Maestral was still (heavily) depending on that version.

[Roy-Orbison]

The function that's failing is in the official SDK, and the relevant endpoint is still part of the V2 API. This stuff is normally caused by incorrect usage, but it could be an issue with either the the SDK or Dropbox service. 🤷

[samschott]

The API call which seems to be failing is /oauth2/token, indeed available in v2. This is used internally by the SDK to exchange a long-lived refresh token stored by Maestral for a short lived auth token used to make all other API calls.

[samschott]

This might just be a temporary glitch on the server side. Let me know if it persists and I'll flag it with the Dropbox support.

[joshstrange]

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.

[frozenpandaman]

Just got this too, fwiw.

[doersino]

Another data point: Popped up for me, too, but now it seems to be working again.

[samschott]

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

[jcguu95]

This issue is gone for me.

[wademaxfield]

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.

[ubidefeo]

Got it once about 1h ago, then sync paused.
No sync issues in the log.
Resumed sync and it is all working again.
It's one of those snafu, I guess 🤷🏼‍♂️

[billyadams]

The issue is occurring for me as well. Happened 3 min ago (2022-05-26 09:58 CDT). It also popped up about an hour ago and when I dismissed I then resumed syncing and all was fine until it popped up again. Shows no syncing errors though.

macOS Monterey 12.3.1, iMac Pro, GUI 1.6.2, daemon 1.6.2

[glynd]

Just to add a +1 - Looks like Dropbox server issue based on the above

[joshstrange]

I don't want to spam this issue but I just saw this error for a 3rd time a minute ago. Unless otherwise asked I won't report future incidents if they are scattered (as in: unless it starts to be a real problem). Right now I'll just ignore it and restart sync.

[lothar-cell]

Same here, also "Connecting..." is displayed more often than not, I wonder if the two issues are connected somehow.

[stevemuench]

This issue happened to me today on two separate computers (Mac mini M1 and MBP M1 both running 12.4). I selected Resume Synching and it seems to have continued after that.

[Roy-Orbison]

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

[samschott]

@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.

[347Online]

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.

[jasongregori]

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.

[kurokirasama]

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

[TorontoPolarBear]

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

[Roy-Orbison]

@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.

[mohamednazmi]

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

[jmfd]

@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.

[theandrewwade]

Data point: Happened quite a bit a week or two ago. Nothing since, but just got it twice today. macOS12.4 and v1.6.2.
"OK" and "Resume sync" makes it go away for a while.

[hb9eue]

Just to provide an additional data point. This started happening to me about one week ago. Now it happens in a minute base. I can unpause sync, and about 10min later, I get this error.

I work on a shared project with a lot of changes on the files. So this could cause this to pop up so frequently to me.

[maiksd]

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

[TorontoPolarBear]

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?

[hb9eue]

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.

[tempelmann]

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?

[neugrin]

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?

Your code works by me. Thanks

After a while I got "Unexpected error" ... like ricir wrote.

[jrc03c]

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

[danielcs88]

1. dropbox_client.py

Does anybody know if there is a similar fix for anyone that has Maestral installed through the App Bundle?

[tempelmann]

1. dropbox_client.py

Does anybody know if there is a similar fix for anyone that has Maestral installed through the App Bundle?

You mean the Mac installer? That does install only a compiled version of the file ("dropbox_client.pyc"), which one cannot edit that way. Maybe there's a way to replace that with an uncompiled version, but I don't know about that.

[kurokirasama]

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?

I tried this in ubuntu, on the file ~/.local/lib/python3.8/site-packages/dropbox/dropbox_client.py, the issue persist, but way less frequently

[kurokirasama]

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?

I tried this in ubuntu, on the file ~/.local/lib/python3.8/site-packages/dropbox/dropbox_client.py, the issue persist, but way less frequently

EDIT: nope, the problem persist

[mileusna]

I get this dialog a lot these days. I even switched to native Dropbox client 😇, but it was such a resource hog compared to Maestral, so I switched back to Maestral today, but I got the dialog again already.

MacBookPro M1 Pro (AppleSilicon)

[acantril]

It started to happen to me multiple times an hour when i'm syncing anything...
I'm going to have to move away i think - i can't deal with the risk.

[mileusna]

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. 🤷‍♂️

[frozenpandaman]

Does anybody know if there is a similar fix for anyone that has Maestral installed through the App Bundle?

You mean the Mac installer? That does install only a compiled version of the file ("dropbox_client.pyc")

Same when installing via Homebrew.

[ufopsi]

It'd be nice if Maestral simply ignored the error and kept syncing - all automatically behind the stage.

[spoxies]

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).

[ricir]

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?

Just tried. It seems OK when I create or modify a file but if I delete files from my Dropbox folder I get:
"Unexpected error. Please restart to continue syncing"

[samschott]

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.

[frozenpandaman]

FWIW I just got the error once more, running v1.6.3.

[samschott]

That's surprising. Calls which raise this error are now retired up to 5 times before it is propagated to the user. This indicates things getting worse on the Dropbox side.

[rmaspero]

I just updated and restarted the sync and got the error within 5 minutes again. Wonder if it is something to with how Dropbox have recently rearranged how Business account folders are structured, that is triggering the error more often?

However has now been running for a few hours happily, might have just been unlucky.

[slifty]

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!

[mileusna]

Zero issues after update couple days ago. 👍

[Mostxlnt]

Same here, no problems since the new update. Thanks Sam!

…

On Tue, 7 Jun 2022, at 17:01, Miloš Mileusnić wrote: Zero issues after update couple days ago. 👍 — Reply to this email directly, view it on GitHub <#683 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMXKI7VRKDQ55GGQAT2SUNLVN5P47ANCNFSM5WXXYVEA>. You are receiving this because you commented.Message ID: ***@***.***>

[neugrin]

Thank you, Sam, I'm on Linuxmint, no error, maestral runs fine again. :)

[samschott]

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