[SERVER-60788] merge_causes_infinite_loop.js attempts to expose a problem that no longer exists Created: 18/Oct/21  Updated: 29/Oct/23  Resolved: 03/Dec/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.2.0, 5.1.2, 5.0.6, 4.4.11

Type: Improvement Priority: Major - P3
Reporter: Jennifer Peshansky (Inactive) Assignee: Mihai Andrei
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
related to SERVER-42137 Allow aggregation $merge stage to wri... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v5.1, v5.0, v4.4
Sprint: QE 2021-11-15, QE 2021-11-29, QE 2021-12-13
Participants:

 Description   

In merge_causes_infinite_loop.js, we attempt to expose the Halloween problem with a $merge pipeline that writes to the same collection that is aggregated. The test assumes that this will cause documents to be updated and pushed forward indefinitely, which will cause the computed values to eventually overflow. As such, after writing to the same collection that is aggregated, the test used to have this assertion that it fails with an overflow error.

The error code in the assertion corresponds to this uassert, which $multiply will no longer trip as a result of SERVER-60588's changes to the implementation. Therefore, I removed the assertion as a part of that ticket, to avoid failures of this test.

In the process, I realized that this assertion has been succeeding not because there was an infinite loop, as the test assumes, but simply because the starting value of $a was high enough to trip an overflow even when only updating once, as expected. Moreover, I realized that even when writing to the same collection that is being aggregated, each document's value of $a was updated only once. Therefore, the Halloween problem does not actually exist for $merge at the moment.

We need to re-evaluate whether we still need this test, and what exactly we want it to be searching for.



 Comments   
Comment by Githook User [ 17/Dec/21 ]

Author:

{'name': 'Mihai Andrei', 'email': 'mihai.andrei@10gen.com', 'username': 'mtandrei'}

Message: SERVER-60788 Update 'merge_causes_infinite_loop.js' to demonstrate the halloween problem (cherry picked from commit d77b27f4baa8139ef8baa48d1588342e95cae389) (cherry picked from commit 11e9d81741e822df6eacfbf2fe065cc7e63388f9) (cherry picked from commit fcedcd3cd0e30b40666435e2777a0f86a5ef3ed0)
Branch: v4.4
https://github.com/mongodb/mongo/commit/3b30ac38838cef1ca8b080c4c740fa41c62de887

Comment by Githook User [ 16/Dec/21 ]

Author:

{'name': 'Mihai Andrei', 'email': 'mihai.andrei@10gen.com', 'username': 'mtandrei'}

Message: SERVER-60788 Update 'merge_causes_infinite_loop.js' to demonstrate the halloween problem

(cherry picked from commit d77b27f4baa8139ef8baa48d1588342e95cae389)
(cherry picked from commit 11e9d81741e822df6eacfbf2fe065cc7e63388f9)
Branch: v5.0
https://github.com/mongodb/mongo/commit/fcedcd3cd0e30b40666435e2777a0f86a5ef3ed0

Comment by Githook User [ 15/Dec/21 ]

Author:

{'name': 'Mihai Andrei', 'email': 'mihai.andrei@10gen.com', 'username': 'mtandrei'}

Message: SERVER-60788 Update 'merge_causes_infinite_loop.js' to demonstrate the halloween problem (cherry picked from commit d77b27f4baa8139ef8baa48d1588342e95cae389)
Branch: v5.1
https://github.com/mongodb/mongo/commit/11e9d81741e822df6eacfbf2fe065cc7e63388f9

Comment by Githook User [ 03/Dec/21 ]

Author:

{'name': 'Mihai Andrei', 'email': 'mihai.andrei@10gen.com', 'username': 'mtandrei'}

Message: SERVER-60788 Update 'merge_causes_infinite_loop.js' to demonstrate the halloween problem
Branch: master
https://github.com/mongodb/mongo/commit/d77b27f4baa8139ef8baa48d1588342e95cae389

Comment by Kyle Suarez [ 19/Nov/21 ]

mihai.andrei – thank you for the analysis; I was mistaken in thinking that the problem had just "gone away". Let's update the test.

Comment by Kyle Suarez [ 22/Oct/21 ]

Sending to mihai.andrei to understand why we aren't infinite looping anymore.

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