-
Bug
-
Resolution: Obsolete
-
Major
-
None
-
None
Regardless of storing command invocations, reading value on backup owner in non-tx cache can always lead to publishing value that should not ever been in the cache:
1. initial value is A
2. T1 calls replace A -> B, backup stores this value, primary is delayed
3. T2 reads value B
4. T3 puts C, currently blocked at primary
5. topology change, both T1 and T3 have to retry
6. T3 retries and updates both primary and backup
7. T1 retries and returns false, because the current value is C, not A
Therefore, B should have never been stored in the cache but it was observed there.
Recording the operation T1 on primary cannot help, because we would be in a similar situation if primary crashed and we had two backups - the backup that becomes primary might not have received the operation at all.