Calendar shared via JMAP Calendar/set with Read Items / read-write is not propagated to the ACL index (SUBSPACE_ACL) — grantee never sees it (PostgreSQL backend)

Issues
4

A lot of the analysis here looks like it came from an AI model reading the source, and it is incorrectly analyzing things. The references to SUBSPACE_ACL, build_access_token, AclQuery::HasAccess and the “archive and index are permanently desynchronized” conclusion are inferences, not something the symptom actually proves, and they are sending the investigation down a very specific rabbit hole that the evidence does not support.

What is genuinely useful in your report is the observable part: as user B, the session does not list A, and B cannot see A’s calendar, even though Calendar/get on A shows B’s grant. That is a real thing to chase. The rest is a guess about the internal cause.

On that guess: the Calendar/set sharing path writes the archive and the ACL index together, in the same atomic batch, and this is covered by the integration tests for calendars, address books and files. A fresh share of A to B does grant access and does populate the index in those tests. So there is no general defect in the write path that would explain a brand new share landing in the archive but not the index. The single row you dumped is also an unrelated share, not the A to B grant you were testing, so it does not actually show the missing row, only that the table has one entry.

A much more likely explanation for “B’s session does not include A” is the access token cache for B not being refreshed, rather than anything in the ACL table. If B was holding a session or token from before the share, it would not pick up the new grant until invalidated.

To get anywhere, could you try a clean reproduction:

  1. Create two brand new accounts, A and B.
  2. As A, share a calendar with B once.
  3. As B, open a fresh session and check whether A appears.

If that fails on fresh accounts, please share the exact requests and responses for those three steps. Also let me know your deployment: single node or cluster, and whether this instance was ever restored, imported or migrated. If it only happens on your existing data and not on fresh accounts, it is most likely pre-existing state on that instance rather than a bug in the current sharing code.