[SERVER-47344] agg_merge_upsert_supplied_cluster.js failure due to unsupported downgrade version Created: 06/Apr/20 Updated: 29/Oct/23 Resolved: 22/Apr/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.0-rc3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tammy Bailey (Inactive) | Assignee: | Bernard Gorman |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | qexec-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Sprint: | Query 2020-04-20, Query 2020-05-04 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Linked BF Score: | 50 | ||||||||||||||||||||
| Description |
|
The JS test agg_merge_upsert_supplied_cluster.js is failing in multiversion testing due to (at least in part) using an illegal downgrade version for testing. The test performs upgrade/downgrade scenarios between 4.4 and 4.2.1, which is not a supported path. I believe the supported downgrade version is 4.2.6.
|
| Comments |
| Comment by Githook User [ 22/Apr/20 ] | ||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Bernard Gorman', 'email': 'bernard.gorman@gmail.com', 'username': 'gormanb'}Message: | ||||||||||||||||||||||||||||||||||
| Comment by Kelsey Schubert [ 16/Apr/20 ] | ||||||||||||||||||||||||||||||||||
|
bernard.gorman, do you have an idea of when this will be ready to push into 4.4? I'd like to the required builders green on 4.4. | ||||||||||||||||||||||||||||||||||
| Comment by Alexander Gorrod [ 13/Apr/20 ] | ||||||||||||||||||||||||||||||||||
|
daniel.gottlieb sorry for the slow reply. Writing out version 4 log files after seeing one in 4.2 is clever. It's a behavior change we wouldn't normally introduce in a dot release, but I don't see any downsides. It seems we have test coverage for it, and the failure won't be subtle if we get it wrong. | ||||||||||||||||||||||||||||||||||
| Comment by Luke Chen [ 09/Apr/20 ] | ||||||||||||||||||||||||||||||||||
|
daniel.gottlieb Hope to let you know | ||||||||||||||||||||||||||||||||||
| Comment by Daniel Gottlieb (Inactive) [ 08/Apr/20 ] | ||||||||||||||||||||||||||||||||||
I do think there's a cleaner way to fail, though because 4.2.1 -> 4.2.4/5 are already released, we can't put in a better log message: So long as the require_min/require_max compatibility works in 4.2.6 for seeing a log version 4 record via a downgrade (compatibility: 3.3), 4.2.6 could choose compatibility=(release=3.3) instead of compatibility=(release=3.2). This would cause 4.2.6 that's working on 4.4 datafiles to only write out log version 4, preventing an earlier 4.2 release from getting passed startup. | ||||||||||||||||||||||||||||||||||
| Comment by Alexander Gorrod [ 08/Apr/20 ] | ||||||||||||||||||||||||||||||||||
No - that is expected to fail, and we have no way of making it fail elegantly. Once a user has opened their database with 4.4, it is no longer safe for them to open the database with a version of MongoDB earlier than 4.2.6 - even stepping through 4.2.6. cc kelsey.schubert and brian.lane I hope that matches your expectations? | ||||||||||||||||||||||||||||||||||
| Comment by Daniel Gottlieb (Inactive) [ 08/Apr/20 ] | ||||||||||||||||||||||||||||||||||
|
I tried running this patched version with keith.bostic's fix for 4.2.6. However, the downgrade process of 4.4 -> 4.2.6 -> 4.2.1 (to reset the test) appears to fail:
alexander.gorrod is 4.4 -> 4.2.6 -> 4.2.1 expected to work? | ||||||||||||||||||||||||||||||||||
| Comment by Daniel Gottlieb (Inactive) [ 08/Apr/20 ] | ||||||||||||||||||||||||||||||||||
|
I talked with bernard.gorman about this test. We believe applying the following patch works:
However, I'm finding data corruption (collection/index out of sync) on downgrade. I expect this is related to |