Currently, sessions do not fully support upgrade/downgrade. In particular, the LogicalSessionsCache does not handle the scenario with FCV 3.6 downgrade to FCV 3.4.

Suggested Fix

1. When mongod detects that FCV is set to 3.4 in 3.6 binary it will delete the sessions collection
2. mongod will be closing all sessions except the sessions that have active operations
3. mongos will be able to find out that the sessions collection does not exist and also will be closing all sessions that are in cache but not the part of the active operation
4. mongod and mongos will keep accepting new sessions to mitigate the potential problem when drivers will not discover that server does not support sessions any more via checking logicalSessionsTimeoutMinutes
5. stop setting logicalSessionsTimeoutMinutes in the isMaster response

Workaround

In the case FCV is set to 3.4 to 3.6 the sessions collection will exist and on a sharded cluster mongos will not be able to detect that it should stop sending the logicalSessionsTimeoutMinues field in the isMaster response. Hence drivers per the spec will keep creating sessions implicitly and it may lead to exceeding the maximum 1000,000 sessions limit.
To avoid it a user can consider manually deleting the config.systems.sessions collection in this scenario. Then mongos with the fix for SERVER-37631 will be able to detect the FCV change and will stop sending logicalSessionsTimeoutMinutes field.

Its critically important to be sure that the refresh thread that updates logical sessions cache is not running on the config server when dropping the config.systems.sessions collection as it may cause a config server crash per SERVER-36904