Shared sub-folder diverges from its group-shared virtual repo after folder revert (silent split-brain)

Server info

• Seafile CE 12.0.14 (Docker), single node
• Client: SeaDrive 3.0.24 on Linux (group members), also visible in web UI

Setup

Library "MPSe" owned by user A contains sub-folder /MPSE Kinh doanh, shared to 3 groups with rw permission (folder share to group). Group members see it as a shared library (virtual repo).

What happened

Between Sep 9-13 the folder was reverted to an older commit (web UI "Revert this folder", API PUT /api2/repos/<origin>/dir/revert/) and once restored from trash after an accidental delete. After these operations the group-shared "library" silently diverged from the real folder in the origin library:

• GET /api2/repos/<origin>/dir/?p=/ shows the folder now has a NEW dir-id (changed by the revert)
• the virtual repo root still points to the OLD dir-id
• writes through the group view and writes through the origin library land in two DIFFERENT directory trees: files uploaded via one path never show up in the other (14 files diverged over 4 days before anyone noticed)
• no error anywhere, both sides keep "working" - silent split-brain

Expected

The virtual repo binding should follow the folder's current dir-id (or the share should break loudly), not silently keep serving a stale tree.

Workaround (confirmed working)

1. Unshare the folder from all groups: DELETE /api2/repos/<origin>/dir/shared_items/?p=...&share_type=group&group_id=...
2. Delete the stale virtual repo: DELETE /api2/repos/<vrepo_id>/ (it is virtual, data lives in the origin)
3. Re-share the folder: PUT /api2/repos/<origin>/dir/shared_items/?p=... with share_type=group, group_id, permission

The new virtual repo is created with root == current folder dir-id; both trees unified again. Verified with cross-write tests both directions (5s propagation) and a full recursive diff (1308/1308 files intact, 0 lost).

Note: re-sharing WITHOUT deleting the stale virtual repo does not heal anything - the server reuses the stale vrepo id.

Related API quirks on CE 12.0.14 (possibly separate issues)

• POST /api2/repos/<id>/dir/shared_items/ only updates permission of an existing share, but returns {"success": true} when asked to "share" a folder that is not shared yet - no share is created, very misleading
• GET /api2/repos/<id>/dir/shared_items/?p=... returns a truncated list (~3 entries) when the folder is shared to many groups