In the sharded cluster case, these lines in list_all_sessions.js, where it asserts that the first session ID in the $listSession output will always match the session ID started by the user1@admin user, will sometimes fail because it relies on the assumption that only that session is active when it refreshed the config.system.sessions collection through the preceding refreshLogicalSessionCacheNow command.

Recent changes to FTDC breaks this assumption, since the ClusterServerParameterRefresher (which services a getClusterParameter command by the FTDC periodic metadata collector during startup) starts its own internal session. By the time refreshLogicalSessionCacheNow is called, there may be more than one active session to be upserted into the session collection with the same lastUse timestamp. This causes the success of the assertion to depend on the ordering of the $listSesisons aggregation output.