[SERVER-25206] Rename 3.2 failMigrationReceivedOutOfRangeDelete and master failMigrationReceivedOutOfRangeOperation failpoint to coincide Created: 22/Jul/16  Updated: 05/Apr/17  Resolved: 28/Oct/16

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

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Dianna Hohensee (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-26828 unblacklist tests in the sharding_las... Closed
is related to SERVER-25153 Add mixed version shards to sharding_... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2016-11-21
Participants:

 Description   

migration_with_source_ops.js is currently blacklisted in the new sharding_last_stable_mongo_and_mixed_shards suite. This is because a 3.2 shard cannot set a failpoint it does not have, which the 3.4 JS test calls.

3.4 migration_with_source_ops.js exercises two points in the code with the same failpoint, whereas in 3.2 migration_with_source_deletes.js only exercises one of those point. If the name of the failpoint were the same, the test could run, if only be 50% effective failpoint-wise with a 3.2 shard – it does nothing incorrect.



 Comments   
Comment by Dianna Hohensee (Inactive) [ 28/Oct/16 ]

About to release 3.4, and then these failpoint name incompatibilities between 3.2 and 3.4 will no longer be an issue. The tests can be unblacklisted in 3.5, when the sharding_last_stable_mongos_and_mixed_shards suite runs 3.6 and 3.4.

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