[Bug]: Mac OS VFS: Exclamation mark on sync status but no easy way to tell what's wrong

[marcotrevisan]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

On the 3.14-macOS-vfs clients that we are using, we often see the exclamation mark icon on the status bar. Hovering on it, it says the vfs sync had an issue.
However, opening the settings panel and clicking on "Create debug archive" freezes the UI and the Nextcloud process becomes unresponsive. This seems to be related (kind of a side effect) to the sync issue itself, because when the sync status is OK, it's possible to generate the debug archive without freezes.

The problem is, I have no clue on what the problem is and therefore haven't found a way to prevent/work around it.
...

Steps to reproduce

1. Have the client running for at least some hours.
2. The client shows an exclamation mark on the status bar, complaining the last sync had an issue.
3. Open the settings panel and click on "Create debug archive"
   ...

Expected behavior

The debug archive should be created.
Observed behaviour: the panel hangs and the process becomes unresponsive, I have to kill it.
Seems similar to what happened a few versions back, on opening the settings panel, where the process froze and needed to be killed.
...

Which files are affected by this bug

Operating system

macOS

Which version of the operating system you are running.

Sonoma 14.6.1

Package

Official macOS 12+ universal pkg

Nextcloud Server version

29.0.6

Nextcloud Desktop Client version

3.14.0-vfs

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.4.2 to 3.4.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

No response

Additional info

No response

[marcotrevisan]

By reopening the client (i.e. quitting and relaunching the app) brings back the sync status to OK.
The debug archive contains some errors, in the current case:

Very frequently:
Nil deleted metadatas received in change read at https://.../remote.php/dav/files/user for user: user https://...

Much less frequently:
err: Error while sending authentication request to nextcloud: Error while connecting to nextcloud: error sending request for url (https://.../index.php/apps/notify_push/uid

and also:
1 depth read of url https://.../remote.php/dav/files/user did not complete successfully, error: Impossibile trovare un server con il nome host specificato. (this looks like a DNS lookup failure)

[marcotrevisan]

Last but not least: if possible, it would be great to add timestamps at the beginning of each line in the debug log file.

[marcotrevisan]

This issue might be related to #7240 and hopefully closed by it as well.

[marcotrevisan]

@claucambra I need to add more info to this issue about the client behaviour.
The 3.14.0 and 3.14.1 versions (mac OS vfs) seem to bring back a performance issue that makes the client almost unusable, at least on our shares, which are fairly large.
The FileProviderExt process is often consuming 100% of one core. I don't know if this is a known issue.
I had to revert to 3.13.4 which doesn't seem suffer from this problem (it does suffer from other issues however, which are solved by 3.14.0).

The console log shows some error lines and among those, I saw some "watchdog" like messages about high CPU consumption by the FileProviderExt process.
So I wonder wether the exclamation mark can arise because of a timeout in sync time or a stop because of too high CPU consumption?

The end result is that FInder is often (not always) very slow in opening folders that were not previously opened, and also in opening files, I guess this happens simply because the FIleProviderExt process is busy.

Let me know if you need console logs, I'll attach them.
Thanks and regards,

[marcotrevisan]

I've opened #7326 for the Finder slowdown problem, adding more info.