In https://couchbasecloud.atlassian.net/browse/MB-47813#icft=MB-47813 we introduced the ability for XDCR to strip certain transaction-related XATTR from the document.

If the DCP has been tagged with SnappyDataType, then XDCR will decompress the body, and then look for the associated XATTRs.
http://src.couchbase.org/source/xref/6.6.5/goproj/src/github.com/couchbase/goxdcr/utils/utils.go#3137-3162

Then, we would strip out the attribute here:
http://src.couchbase.org/source/xref/6.6.5/goproj/src/github.com/couchbase/goxdcr/parts/filter.go#208-252

We would keep the modified body:
http://src.couchbase.org/source/xref/6.6.5/goproj/src/github.com/couchbase/goxdcr/parts/filter.go#145-159
as wrappedUprEvent.DecompressedValue

If we need to use the body that has been stripped of the transaction related XATTR, then XDCR would recompress the body depending on whether or not SnappyDataType was set:
http://src.couchbase.org/source/xref/6.6.5/goproj/src/github.com/couchbase/goxdcr/parts/router.go#164-185

From a customer situation, analysis shows:

The first 4 bytes in the payload store the size of the Xattr block (2065855349) -> Invalid, the size of the Xattr block can't be greater than the size of the entire value

This means XDCR has not modified the first 4 bytes of the body to update the actual xattrSize. Thus, it is entirely possible that:

• The document itself originally has no xattribute but is being staged by transaction so it has transactional xattribute, so xattrSize is > 0 and document has XATTR flag tagged

• XDCR strips of the txn XATTR and recompresses body but left the body format as is. The body technically no longer has any xattr and body starts with user data.

• The memcached packet has XATTR flag set and non-0 XATTR size (first 4 bytes of body), and XATTR flag is still set.

• Due to the flag, KV reads the first 4 bytes of the payload and finds an invalid XATTR block because it is really user data.

The same needs to be done (updating XATTR size portion of memcached body) even if there are existing customer XATTRs.

EDIT:
The issue is if a document only consists of transaction XATTR, XDCR will strip it. The body will no longer contain XATTR, and thus body[0:4] contains actual user data instead of xattr size. However, XDCR is not clearing the XATTR data type and thus KV will try to parse the first 4 bytes, which is not valid.