Details
-
Bug
-
Resolution: Fixed
-
Major - P3
-
None
-
None
-
None
-
Fully Compatible
-
ALL
-
-
35
Description
The failure in tenant_migration_logs.js happens here (https://github.com/10gen/mongo/blob/master/jstests/replsets/tenant_migration_logs.js#L20). The function checkLog calls the getLog command (https://www.mongodb.com/docs/manual/reference/command/getLog/) which returns the 1024 most recent log lines. The assertion checks if the logs have
RegExp(`Slow query.*recipientForgetMigration`). The failure happens because we log more than 1024 lines before checking the log. When looked at, the task logs do contain "recipientForgetMigration," however, it is not there in the log lines returned by getLog.
The runMigrationCommand (https://github.com/10gen/mongo/blob/master/jstests/replsets/libs/tenant_migration_test.js) has automaticForgetMigration enabled by default. This calls forgetMigration for the donor and then the recipient once the migration is complete. In the test, after calling runMigration, forgetMigration is manually called again and then we check the logs for RegExp(`Slow query.*recipientForgetMigration`). Before checking the logs, we perform a few other operations.
If we disable automaticForgetMigration and then call forgetMigration manually right before the checking the logs, the chances of more than 1024 lines being logged would be minimal.
Another issue that was unearthed during investigation was the possibility of the second forgetMigration failing. The forgetMigration command sets the expiresAt field for garbage collection. If garbage collection happens before the call to the second forgetMigration, we will get a failure since we have already cleaned up.