Starting in 5.0, XATTRs is a public feature of the system. While SDKs will cover the API and usage and how errors are returned, the details on those errors and the limitations of XATTRs itself needs to be centralized.
This issue would be done when Couchbase Server documentation has a section that covers:
- Error codes including the hex value, text returned, and a description of the error condition
- A description of limitations in the implementation (e.g., XATTR mutations must come before non-XATTR mutations always), as this is not generally enforced in the API
- A description of what the interface stability is for these features if there are any that are not committed interface
This may be tracked somewhere already by Chin Hong's team (maybe Tyler Mitchell?).
On that last bullet item, there are some things like retrieving XATTRs from deleted documents which are considered "Internal". See (https://developer.couchbase.com/documentation/server/current/sdk/java/compatibility-versions-features.html#topic_bhl_2cv_xv__d298e17) for a definition of interface stability. I don't think anything Internal should be covered in these docs, but anything Volatile or Uncommitted should, if there is such a thing.