[CBG-4603] Better Handling of Pushed Deltas when a client doesn't have Access to its Parent Revision

Product: Sync Gateway
Component: sync-gateway
Issue Link: CBG-4603
Affects Versions: 2.x, 3.0.x, 3.1.x, 3.2.x
Fix Version: 3.3.0

Summary

• This issue appears as 404 Document revision is not accessible during push replication when delta sync is enabled and the base revision is not readable by the replicating user, causing the Sync Gateway side delta application to fail.
• When a new revision is pushed under delta sync, Sync Gateway computes a delta against a stored base. If the user lacks access to that ancestor, the push fails with 404 instead of accepting the change via delta.
• The behavior reflects normal access control: users can only read documents in channels to which they are granted access, and delta sync relies on prior revision bodies to compute and apply deltas.
• Practical resolutions are to grant the replicating user access to the parent revision’s channels or disable delta sync so replication uses full-document bodies instead of deltas.

Symptoms 

• Push replication fails on specific documents with a 404 Document revision is not accessible on Type:rev frames during a delta push.
• Logs typically show delta negotiation and a DeltaSrc pointing to the ancestor revision that the server attempted to use as the base for delta computation.

Triggers

• A document’s initial revision is created without being routed to any channel that the replicating user can read, followed by a later push of a new revision by that user while delta sync is enabled (so the server expects to use the earlier revision as the delta base).
• Because access is enforced via channels, attempting to push over an ancestor that is not readable by the replicating user triggers failure when the server tries to use that inaccessible base as DeltaSrc.

Verification

• Verify that delta sync is enabled at the database level; delta sync is disabled by default and must be turned on in the Database Configuration. When enabled, Couchbase Lite automatically negotiates delta mode during replication.
• Confirm negotiation in logs: For example, a proposeChanges response often indicates deltas=true when delta sync is active:

2025-04-08T14:28:47.823Z [DBG] c:[f189ecd] db:db col:_default Setting deltas=true property on proposeChanges response

• Inspect the failing push for a Type:rev frame with DeltaSrc and a 404 result, indicating the server could not apply the delta because the base revision was not accessible:

2025-04-08T14:28:47.882Z [DBG] SyncMsg+: c:[f189ecd] db:db col:_default #3: Type:rev Id:<ud>Test:0c3e768ff9d9</ud> Rev:4-1f5d1c58f1426b979698ce5778a92a98e1e3ffc6 DeltaSrc:1-1d70abec21bf00dd87ca396780bac954d89f6f54 Sequence:64980 NoConflicts:1 
2025-04-08T14:28:47.886Z [INF] SyncMsg: c:[f189ecd] db:db #3: Type:rev   --> 404 Document revision is not accessible Time:3.353957ms

• This pattern shows a delta attempt referencing an ancestor and failing with access denial on that base revision.
• Validate access control: a user can read documents only if the document is assigned to at least one channel to which the user (or role) is granted access, so the ancestor revision used as DeltaSrc must be readable under the user’s channel membership.
• Important: Rule out reserved-property conflicts by inspecting the client-side document (from Couchbase Lite) and ensuring it does not include reserved top-level properties such as "_removed" or "_rev", which are disallowed and unsupported.

Workarounds

• Grant the replicating user access (directly or via role) to the channel(s) containing the parent revision so that the ancestor referenced by DeltaSrc is readable and the delta application can succeed.
• Disable delta sync on the affected database to force full-document replication instead of deltas, eliminating the dependency on reading the ancestor revision during a push.