[SERVER-36563] forcePrimaryRefreshAndWaitForReplication fails to parse operationTime with FCV=3.4 Created: 09/Aug/18  Updated: 11/Jul/20  Resolved: 20/Aug/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.6.6
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Kaloian Manassiev
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-36248 Do not reject sessions in FCV 3.4 Closed
Operating System: ALL
Participants:
Case:

 Description   

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.



 Comments   
Comment by Misha Tyulenev [ 20/Aug/18 ]

kaloian.manassiev as we discussed offline - the fix in https://jira.mongodb.org/browse/SERVER-35795 should fix the issue

Comment by Kaloian Manassiev [ 20/Aug/18 ]

Starting with version 3.6.7 (and specifically with the fix for SERVER-36248, the setup of the sessions sharded collection will not happen until FCV reaches 3.6 and therefore this bug no longer exists.

Closing as duplicate of SERVER-36248.

Comment by Kaloian Manassiev [ 20/Aug/18 ]

misha.tyulenev, should this be fixed at the level of the sessions cache to do set-up the config.system.sessions collection at all?

Alternatively, I think we can fix it in ShardServerCatalogCacheLoader::getChunksSince by checking whether the FCV is 3.4, however I think it is more appropriate to do it in the sessions code.

Generated at Thu Feb 08 04:43:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.