Normally CAS isn't checked in the success cases, except when waiting on data to be persisted. Previously the library failed to update the CAS value on success causing WriteUpdate calls with the Index/Persist flags set to always fail with ErrOverwritten. These were false errors, as the library was always using the pre-modification CAS value as input into the observe function instead of the post-modification CAS value. cbugg: close bug-849
This really isn't generally a fatal error, but the error does show up in a situation where protocol error causes the stream to fall out of sync. The server will hang up, but the client won't know it yet. This generally happens with a key that's too long for the server. e.g. this test sets a value in a short key, then a long key, then tries to read the value out of the short key again using the couchbase API. before: len(longString) == 260 Return: MCResponse status=EINVAL, opcode=SET, opaque=0, msg: Invalid arguments EOF after: len(longString) == 260 Return: MCResponse status=EINVAL, opcode=SET, opaque=0, msg: Invalid arguments x is "test" cbugg: close bug-304
Legit server errors updating a value (e.g. E2BIG) would cause CASNext to think there was a conflict and tell the client to try again, resulting in an infinite loop.
The original functional form of CAS() is problematic for go-couchbase because it results in the memcached connection staying in use while the client callback is running. The new form returns to the caller after every iteration, so the caller doesn't need to reserve the connection. This will help fix a deadlock issue with go-couchbase and the sync gateway. (See couchbase/sync_gateway#119)