[SERVER-31356] make OplogEntry immutable Created: 02/Oct/17  Updated: 30/Oct/23  Resolved: 08/Nov/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 3.5.13
Fix Version/s: 3.6.0-rc4

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Benety Goh
Resolution: Fixed Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-31753 Add support for immutable IDL types Closed
Related
related to SERVER-31705 IDL should automatically create == an... Closed
related to SERVER-32918 Make OplogEntry class useful for part... Closed
is related to SERVER-36570 Make OplogEntry mutable Closed
is related to SERVER-29200 Limit access to OplogEntry::raw Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2017-11-13
Participants:

 Description   

Current definition of == compares the 'raw' member variable. The 'raw' variable is only set in the constructor. If the object is mutated after, for example, calling setFromMigrate(), then it will no longer match the actual object.



 Comments   
Comment by Githook User [ 08/Nov/17 ]

Author:

{'name': 'Benety Goh', 'username': 'benety', 'email': 'benety@mongodb.com'}

Message: SERVER-31356 remove unused OplogEntry constructors
Branch: master
https://github.com/mongodb/mongo/commit/5ab490e943395019a08ed088290aa462d8e310ad

Comment by Githook User [ 08/Nov/17 ]

Author:

{'name': 'Benety Goh', 'username': 'benety', 'email': 'benety@mongodb.com'}

Message: SERVER-31356 update the following tests to use new OplogEntry constructor

AbstractOplogFetcher
InitialSyncerTest
MultiApplierTest
SyncSourceResolverTest
Branch: master
https://github.com/mongodb/mongo/commit/c5d53097eb9090e293410d6667187261e9ff09e7

Comment by Githook User [ 07/Nov/17 ]

Author:

{'name': 'Benety Goh', 'username': 'benety', 'email': 'benety@mongodb.com'}

Message: SERVER-31356 make OplogEntry immutable
Branch: master
https://github.com/mongodb/mongo/commit/1359451aec50864d923d8493a9b3f07949548cf2

Comment by Githook User [ 07/Nov/17 ]

Author:

{'name': 'Benety Goh', 'username': 'benety', 'email': 'benety@mongodb.com'}

Message: SERVER-31356 update the following unit tests to not mutate OplogEntry after construction

ChangeStreamStageTest
SessionCatalogMigrationDestinationTest
SessionCatalogMigrationSourceTest
SessionHistoryIteratorTest
SessionTest
SyncTailTest
WriteOpsRetryabilityTest
Branch: master
https://github.com/mongodb/mongo/commit/a8b621d8a3ac790ac95d17323fe8b66558b3cb3f

Comment by Githook User [ 07/Nov/17 ]

Author:

{'name': 'Benety Goh', 'username': 'benety', 'email': 'benety@mongodb.com'}

Message: SERVER-31356 SessionCatalogMigrationSource no longer mutates OplogEntry after construction
Branch: master
https://github.com/mongodb/mongo/commit/d20d01aedf7fac426fe60ba18c1bc59ce97ca060

Comment by Githook User [ 07/Nov/17 ]

Author:

{'name': 'Benety Goh', 'username': 'benety', 'email': 'benety@mongodb.com'}

Message: SERVER-31356 add OplogEntry constructor to support uuid and transaction related fields
Branch: master
https://github.com/mongodb/mongo/commit/a89d0886d305e07c2e07b4ed53c9dbda52f5fb17

Comment by Spencer Brody (Inactive) [ 06/Oct/17 ]

It is required for 3.6 that we at least audit users of OplogEntry to see if any are mutating them while also using == or checking the 'raw' member

Comment by Spencer Brody (Inactive) [ 06/Oct/17 ]

One possible fix for this would be to just make OplogEntry immutable

Comment by Randolph Tan [ 02/Oct/17 ]

spencer I ran into this while writing C++ tests. So far, I don't think I use it on anything else explicitly. On the other hand, this function can potentially be called in places where it would be hard to trace, for example, unordered_map<OplogEntry>. So, it would be beneficial to have the == be correct in all cases.

Comment by Judah Schvimer [ 02/Oct/17 ]

SERVER-29200 was made to remove the raw member. We unfortunately read from it in many places. If we want OplogEntry to be correctly mutable, we may need to first do that ticket as well.

Comment by Spencer Brody (Inactive) [ 02/Oct/17 ]

renctan, can you comment a little more on the scope of this bug? How was it found? Is this causing an actual user-visible bug in any features that utilize this code, or this this just a defensive ticket to prevent it from being misused in the future?

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