[Bug]: (performance) Move of a folder is O(1) operation, but push notification will trigger requests for its nested subfolders too

[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

I had to refactor the position of some large subfolders in my organization's Files tree.
I've noticed that the operation has the following runtime impact:

• the target folder is a "brother folder" of the moved one, in other words source and target folders are initially under the same parent folder. I don't know if this holds also for different scenarios.
• the move itself is O(1) in the server (i.e. only one request is performed) and it finishes in a short and constant time;
• then the push notifications are sent;
• Some v3.10.0 clients (those which are online at the moment), instead of issuing O(1) PROPFIND requests, they also dive into the moved subfolder hierarchy and apparently issue PROPFINDs in a recursive fashion.

Since the moved subfolder is quite large, this is requiring quite a bit of resources on the server (and I guess the clients are also slowed down during this step).

Wouldn't it be just as correct to issue a PROPFIND only for the target folder and assume the moved folder contents are unchanged?
When the move is performed by the client, that client will infact issue the move request but then it will sync its inner database very quickly without any subsequent requests.
It seems reasonable that the other clients should also be able to do the same operation, the only difference being the triggering event (remote vs local).

I hope this helps.
Thanks and regards!

Steps to reproduce

1. Make sure notify_push is enabled and working;
2. Move a large subfolder from a folder to another
3. Watch the server logs for the clients reaction

Expected behavior

The clients will issue a constant number of requests, not diving recursively into the moved subfolder.

Which files are affected by this bug

Subfolders of the moved folder.

Operating system

Mac OS

Which version of the operating system you are running.

Ventura 13.5.2

Package

Other

Nextcloud Server version

27.1.1

Nextcloud Desktop Client version

3.10.1

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

Fresh desktop client install

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]

UPDATE: I checked the impacted clients (those which were issuing the requests) and their configuration didn't include all the source folders in the sync, but only one.
Due to the refactor, the destination folder was automatically included in sync, and the end result was the appearance of all the other moved folders even if they weren't in sync earlier.
I think this is kind of a corner case and the client didn't act worng, it had no other choice but to dowload the other folders as if they were new.
Closing this issue. Sorry for not having spotted all the conditions in the first place.