Details
-
Bug
-
Resolution: Fixed
-
Major - P3
-
None
-
None
-
Fully Compatible
-
ALL
-
Repl 2017-08-21
-
0
Description
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 |
|
136
|
TEST_F(AbstractOplogFetcherTest, OplogFetcherReturnsOperationFailedIfExecutorFailsToScheduleFind) {
|
137
|
ShutdownState shutdownState;
|
138
|
|
139
|
TaskExecutorMock taskExecutorMock(&getExecutor());
|
140
|
taskExecutorMock.shouldFailScheduleRemoteCommandRequest =
|
141
|
[](const executor::RemoteCommandRequest&) { return true; }; |
142
|
|
143
|
MockOplogFetcher oplogFetcher(
|
144
|
&taskExecutorMock, lastFetched, source, nss, 0, stdx::ref(shutdownState)); |
145
|
|
146
|
ASSERT_FALSE(oplogFetcher.isActive());
|
147
|
ASSERT_OK(oplogFetcher.startup());
|
148
|
ASSERT_TRUE(oplogFetcher.isActive());
|
149
|
|
150
|
oplogFetcher.join();
|
151
|
|
152
|
ASSERT_EQUALS(ErrorCodes::OperationFailed, shutdownState.getStatus());
|
153
|
}
|