memcached mismatched return value and result code
- Dominant language
- C++
- Stars
- 18.7k
- Forks
- 3.1k
- Avg merge
- 1h 47m
- Merged PRs (30d)
- 2
Description
### HHVM Version
HipHop VM 3.23.4 (rel)
Compiler: tags/HHVM-3.23.4-0-g90c8bcc5927c21d506a4a4f26b140cdb534e6bed
Repo schema: 8ee590a366600f34f1748ffdfa24d389c13f85fa
hh-fc9898fbdf5f3dca608e09fd83e663a644608bec-3.23.4 Thu Jan 11 17:46:28 2018
### Operating System and Version
CentOS Linux release 7.3.1611
### Standalone code, or other way to reproduce the problem
```
// summon a mysterious storm
$rval = $memcached->cas($casKey, $key, $value, $expires);
var_dump($rval, $memcached->getResultCode() === Memcached::RES_SUCCESS);
```
### Actual result
```
bool(false)
bool(true)
```
### Expected result
```
bool(false)
bool(false)
```
Some (small) percentage of the time, memcached updates (`cas`, `delete`, `set`) return `false`.
A percentage of *those* times, `getResultCode` provides `Memcached::RES_SUCCESS`, even though the return value was false.
About 82% of the times where an update returns `false` but `getResultCode` provides `Memcached::RES_SUCCESS`, the value is *indeed* updated with the correct value.
The other 18% of the time where an update returns `false` but `getResultCode` provides `Memcached::RES_SUCCESS`, the value is *not* updated with the correct value, but it's possible that it was manipulated in another thread.
I can't reproduce this case manually, but we see it hundreds of thousands of times a day, with
non-weird keys/values.
Does anyone have any insight here?
My problem is mostly that the return value doesn't match `getResultCode` - I want to know that if the return value is false, then the value didn't get written to memcached.
Thanks for any help
Contributor guide
Assessment
This issue has not been assessed yet.