-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
ALL
-
Repl 2017-08-21
-
0
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In this test case, it is racy to check OplogFetcher::isActive() immediately after calling startup() because OplogFetcher schedules the remote command on a different thread from the caller of startup().
abstract_oplog_fetcher_test.cpp
TEST_F(AbstractOplogFetcherTest, OplogFetcherReturnsOperationFailedIfExecutorFailsToScheduleFind) {
ShutdownState shutdownState;
TaskExecutorMock taskExecutorMock(&getExecutor());
taskExecutorMock.shouldFailScheduleRemoteCommandRequest =
[](const executor::RemoteCommandRequest&) { return true; };
MockOplogFetcher oplogFetcher(
&taskExecutorMock, lastFetched, source, nss, 0, stdx::ref(shutdownState));
ASSERT_FALSE(oplogFetcher.isActive());
ASSERT_OK(oplogFetcher.startup());
ASSERT_TRUE(oplogFetcher.isActive());
oplogFetcher.join();
ASSERT_EQUALS(ErrorCodes::OperationFailed, shutdownState.getStatus());
}