Sync Gateway 2.5 Fails to Find GCS-Stored Attachments During Replication

I am running Couchbase Lite v3.2 against a Sync Gateway v2.5 and Couchbase v5 on the server. Replication is working except for attachments.

Our Sync Gateway config includes:

“attachmentsGCSBucket”: “kordata-dev-attachments”

I’m seeing replication errors with 404 responses on blob requests like this:

2025-4-9 06:22:27.073+01:00 [47]| ERROR) [Replicator] Obj=/DNRepl@100DE29A8/C4RemoteRepl#4/Repl#5/Puller#11/IncomingRev#29/ Coll=0 Blob request got error response: HTTP 404 ‘missing’

In the mobile app, documents include _attachments with digests such as:

“digest”: “sha1-vHz1gz90NyhtqFZ55QxmnNTvH7M=”

We confirmed these digests match objects inside the Google Cloud Storage bucket kdata-dev-attachments , but some are nested under subfolders like:

kdata-dev-attachments/Utah/photo/00043327…/sha1-vHz1gz90NyhtqFZ55QxmnNTvH7M=

The document references the attachment like this:

“_attachments”: {
“photo.jpg”: {
“content_type”: “image/jpeg”,
“digest”: “sha1-vHz1gz90NyhtqFZ55QxmnNTvH7M=”,
“length”: 121341,
“revpos”: 1,
“stub”: true
}
}

Question: Is Sync Gateway v2.5 capable of resolving blobs from nested paths like that, or must the files exist in the root of the bucket (e.g. gs://kdata-dev-attachments/sha1-…) to be found?

I don’t know what “attachmentsGCSBucket”: “kordata-dev-attachments” means in a Sync Gateway configuration, or how Sync Gateway would reference documents in a GCS bucket.

Sync Gateway attachments are stored as binary documents on Couchbase Server. T blobs are treated opaquely by Sync Gateway.