This bug manifests itself as

2018-08-07T16:06:59.981+1000 I SHARDING [ShardServerCatalogCacheLoader-1] Refresh for collection config.system.sessions took 52 ms and failed :: caused by :: FailedToParse: No operationTime found

in the logs of the secondaries on the config server during upgrade 3.4 -> 3.6 after binaries are upgraded but FCV is still 3.4.
The issue is that in FCV 3.4 mongod does NOT attach operationTime to not confuse drivers (https://jira.mongodb.org/browse/SERVER-29785)
But setupSessionsCollection that is scheduled by LogicalSessionsCache invokes

_checkCacheForSessionsCollection which in turn calls 
CatalogCache::getShardedCollectionRoutingInfoWithRefresh ->
 CatalogCache::getCollectionRoutingInfo ->
 CatalogCache::_scheduleCollectionRefresh ->
_cacheLoader.getChunksSince
which eventually gets to call the  forcePrimaryRefreshAndWaitForReplication (on secondary)

that uasserts because it can not parse the operationTime from the response it gets from the primary because primary is FCV3.4

the bottomline:
The check for FCV 3.4 can be put anywhere in the chain listed above to prevent the logs. The actual bug seems in the design of forcePrimaryRefreshAndWaitForReplication that returns the parsing error of successfully executed command as the command execution error. In the reality the config.system.sessions collection is created successfully.