[SERVER-38860] Positional array update behavior of applyOps on invalid field varies on different versions Created: 05/Jan/19 Updated: 27/Oct/23 Resolved: 18/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Siyuan Zhou | Assignee: | Siyuan Zhou |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Sprint: | Repl 2019-03-25 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
Positional array update of applyOps on an invalid field isn't consistent from 3.2 to 4.0. Here are the test and results from shane.harvey and john.morales.
The behavior is different across releases.
Because of the ambiguity, 0 is interpreted as a field name. However, there is no idempotency concern because if an error is returned, initial sync will refetch the document as if the document is missing; if the update succeeds, other fields are still updated correctly. Whatever intermediate state the field has, it will be cleaned up eventually since a later version doesn't have it. For example, if the field is an array eventually, there must be a $set to set the whole field to a valid array after the problematic update oplog entry.
The bottom lines for the correctness of idempotency are:
|
| Comments |
| Comment by Siyuan Zhou [ 18/Mar/19 ] | |||
|
Given that there's no idempotency issue on replication side, I'm closing this as Work As Designed. | |||
| Comment by David Storch [ 13/Mar/19 ] | |||
|
siyuan.zhou tess.avitabile, I confirmed that in master the applyOps succeeds because the update system is configured with UpdateDriver::setFromOplogApplication(): This causes the $set implementation to suppress any error if the path to create would traverse through an existing scalar: This seems like the correct behavior for oplog application idempotency. That is, it is correct for $set to fail with ErrorCodes::NonViablePath in this case, unless the $set is being done inside oplog application, in which case the error should be suppressed to ensure idempotency. Hopefully this answers any questions that the repl team had for the query team! I did not investigate why exactly the behavior has changed between 3.2, 3.4, 3.6, and 4.0. However, it's clear that the behavior changes were due to how applyOps uses the update subsystem in oplog application, as opposed to behavior changes in the regular update implementation. I'm moving this into the repl team's triage queue. Don't hesitate to let me know if there's anything else I can help with! | |||
| Comment by Craig Homa [ 06/Feb/19 ] | |||
|
Hey david.storch, does Siyuan's comment answer your questions? | |||
| Comment by Siyuan Zhou [ 09/Jan/19 ] | |||
|
david.storch, right, this is a dup of My understanding is the behavioral inconsistency won't lead to data inconsistency in a mixed-version replica set either. | |||
| Comment by David Storch [ 09/Jan/19 ] | |||
|
The following update results in an error on 3.4, 3.6, 4.0, and master:
Therefore, it appears that the changing behavior of applyOps is not due to the update subsystem, but rather is specific to the applyOps code path. | |||
| Comment by David Storch [ 09/Jan/19 ] | |||
|
tess.avitabile siyuan.zhou shane.harvey, how does this ticket differ from | |||
| Comment by Siyuan Zhou [ 05/Jan/19 ] | |||
|
CCÂ tess.avitabile, as the behavior might be caused by the array update project and it's relevant to replication. |