This is a symptom of having to use two separate RPCs (and thus transactions) to add and remove tuples in processing a replication event.

There are two solutions we discussed:

1. First upsert relations, then remove any relations not including those just upserted. This could be done on the side of the sink, or the replication logic (it could just omit those tuples in that case).
2. Add a "write" RPC which can, in one transaction, do any combination of inserts, upserts and removals, and utilize this from the sink.

2 is superior because it's fully atomic (there is also no period where there is excess access) and simpler to use, but involves more work.

Few additional notes:

• We're pretty sure SpiceDB's write will reject a call that has the same tuple in create and remove. If this is the case, the logic to figure out what we "really" want to remove vs create should probably be solved in RBAC. It's the thing that really knows what should be added or removed.
• In which case, the simplest thing to do would be to just reorder the calls in the sink for now and update the RBAC outbox writes to be specific/clear about which should be upserted or removed, and not ambiguously include the same tuple in both.