[SERVER-50778] "Cannot apply $bit" when $bit update grows an array Created: 03/Sep/20  Updated: 29/Oct/23  Resolved: 12/Feb/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Bug Priority: Major - P3
Reporter: pan chen Assignee: Ted Tuckman
Resolution: Fixed Votes: 0
Labels: qopt-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File image-2020-09-03-10-02-12-052.png     PNG File image-2020-09-03-10-02-34-425.png    
Issue Links:
Backports
Depends
Documented
is documented by DOCS-14472 Document that update operators that a... Closed
Duplicate
is duplicated by SERVER-33687 Sort order of array indexes can deter... Closed
is duplicated by SERVER-55554 Fix out of order array element update... Closed
is duplicated by SERVER-56993 [4.4] Update with update modifiers si... Closed
Problem/Incident
Related
related to SERVER-55554 Fix out of order array element update... Closed
Backwards Compatibility: Minor Change
Backport Requested:
v4.4
Sprint: Query 2020-11-30, Query 2020-12-14, Query 2020-12-28, Query 2021-01-11, Query 2021-01-25, Query Optimization 2021-02-22
Participants:
Linked BF Score: 29

 Description   

I use the rs field to store an array of longs. When the rs field is stored to the subscript as eight bits, I use the bit operation to go to the ninth and tenth bits, and an error will be reported.



 Comments   
Comment by Githook User [ 11/Mar/21 ]

Author:

{'name': 'Samuel Mercier', 'email': 'samontea@users.noreply.github.com', 'username': 'samontea'}

Message: TIG-2919 Ban type errors caused by changes to array update (create field) semantics in SERVER-50778 (#417)
Branch: master
https://github.com/10gen/jstestfuzz/commit/48aef3d0a9abf84878f1792abdd8bb9a54eb869d

Comment by Githook User [ 11/Mar/21 ]

Author:

{'name': 'samontea', 'email': 'merciers.merciers@gmail.com', 'username': 'samontea'}

Message: TIG-2919 Ban type errors caused by changes to array update (create field) semantics in SERVER-50778
Branch: tig2919
https://github.com/10gen/jstestfuzz/commit/94a89dbe017e797761d4a67277376ebabcd842e4

Comment by Githook User [ 11/Mar/21 ]

Author:

{'name': 'samontea', 'email': 'merciers.merciers@gmail.com', 'username': 'samontea'}

Message: TIG-2919 Ban type errors caused by changes to array update (create field) semantics in SERVER-50778
Branch: tig2919
https://github.com/10gen/jstestfuzz/commit/853e4f76592f8e303527704372e654ed3488415b

Comment by Githook User [ 12/Feb/21 ]

Author:

{'name': 'Ted Tuckman', 'email': 'ted.tuckman@mongodb.com', 'username': 'TedTuckman'}

Message: SERVER-50778 Compare array indexes numerically for updates
Branch: master
https://github.com/mongodb/mongo/commit/9ebdcb19f24adc3155f896693d9dc8931c0a5b34

Comment by Githook User [ 11/Feb/21 ]

Author:

{'name': 'Ted Tuckman', 'email': 'TedTuckman@users.noreply.github.com', 'username': 'TedTuckman'}

Message: SERVER-50778 Ignore type errors in arrays (#392)

  • Minor fixes
  • add test
  • Fix test to run outside the shell
  • Delete export and test
Comment by Githook User [ 23/Oct/20 ]

Author:

{'name': 'Ted Tuckman', 'email': 'ted.tuckman@mongodb.com', 'username': 'TedTuckman'}

Message: Revert "SERVER-50778 Compare array indexes numerically for updates"

This reverts commit 16b59bd6236a90ad3d807a66ec2fe529e09cf0ec.
Branch: master
https://github.com/mongodb/mongo/commit/713eb42740e27cb6639b30dbad43ba98f8d868ee

Comment by Eric Sedor [ 19/Oct/20 ]

Hi hellotudou@outlook.com, we wanted to clarify that until this change is live, we recommend using numeric order instead of lexicographic order.

That's because of the nature of this bug. We found that the updated array grows correctly except when lexicographic order differs from numeric order. You may still see issues if you try to manipulate a null 9th element with $bit if it was created implicitly when the 10th element was created.

This is only really a problem when the kind of update being performed fails against a null value. Does this make sense?

Comment by pan chen [ 16/Oct/20 ]

thank you,I temporarily update the array subscript in lexicographic order.

Comment by Githook User [ 15/Oct/20 ]

Author:

{'name': 'Ted Tuckman', 'email': 'ted.tuckman@mongodb.com', 'username': 'TedTuckman'}

Message: SERVER-50778 Compare array indexes numerically for updates
Branch: master
https://github.com/mongodb/mongo/commit/16b59bd6236a90ad3d807a66ec2fe529e09cf0ec

Comment by Eric Sedor [ 08/Sep/20 ]

This looks to be an interaction between a few things:

  • $bit is invalid against an explicit null value because it is not of an integer type
  • $bit+or does create a value where none exists.
  • Creating a non-existent array element that grows an array will implicitly create as null any elements necessary for the array to reach that length.

Here, creating an element at rs.10 (the 11th element) in an array of 9 elements implicitly creates a 10th element (rs.9) that is explicitly null, which seems to cause the update to rs.9 to fail even though such an update would succeed on its own (as long as rs.9 was not already null).

I'm passing this ticket on to an appropriate team for consideration. In the meantime, you can work around this by:

  • Initializing to NumberLong(0) all array elements you expect to operate on
  • If adding elements, grow the array sequentially, one element at a time
Comment by Massimiliano Marcon [ 07/Sep/20 ]

hellotudou@outlook.com this does not look like an issue of the MongoDB Shell. Moving to SERVER.

Generated at Thu Feb 08 05:23:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.