autoaccept groups shares may create too much load and not finish all accepts

[butonic]

The current implementation for autoaccept shares needlessly amplifies writes. On a group share with 5k members 5k writes are made to update the received shares status, at least one per member.

Furthermore, when the autoaccept logic iterades over members and is killed by kubernetes it may not have accepted all shares. It will not pick that up because we fetched the event from the queue and ACKed it automatically.

A better solution would be to move the autoaccept code to the share manager implementation itself: whenever a list received shares call is made we already fetch all group shares the user is a member of before fetching the received state for each share (that contains the mountpoint and the pending / accepted / rejected state). We can update any pending shares to accepted on the fly.

This would

• (PRO) reduce the number of writes to the amount of active users
• (PRO) move the functionality to a storage manager implementation, where it belongs
• (PRO) get rid of an event based mechanism that AFAICT may overload the underlying storage
• (PRO) solve data inconsistency whan a group share accept operation was killed by kubernetes while still iterating over the members
• (CON) force every share manager implementation to implement autoaccept on its own.

IMO a reasonable tradeoff.

[rhafer]

• (PRO) reduce the number of writes to the amount of active users

• (PRO) move the functionality to a storage manager implementation, where it belongs

• (PRO) get rid of an event based mechanism that AFAICT may overload the underlying storage

• (PRO) solve data inconsistency whan a group share accept operation was killed by kubernetes while still iterating over the members

• (CON) force every share manager implementation to implement autoaccept on its own.

• (PRO) autoaccept works also for new group members that are added after the share was created

[micbar]

@kobergj @wkloucek I would strongly vote for taking that into account rather earlier than later.

iOPs in general seem to be short, this proposal reduces it significantly.

And it fixes some bad behavior like group members which are added after the share was created.

[wkloucek]

(PRO) autoaccept works also for new group members that are added after the share was created

And it fixes some bad behavior like group members which are added after the share was created.

Could you please elaborate? How is it related to https://github.com/owncloud/enterprise/issues/6958#issuecomment-2464126518 ?

[micbar]

Group shares are auto accepted for all the members of a group at the point in time of the share creation. Members which are added later will see the share, but it will be not synced to the desktop.

NOTE: accepting shares is nowadays called „Sync“ and only has effect on the native clients. For the web client, you do not need to sync a share to work with it.