[SERVER-33798] We should fail operations with an atClusterTime readConcern newer than the current clusterTime Created: 09/Mar/18  Updated: 29/Oct/23  Resolved: 15/Mar/18

Status: Closed
Project: Core Server
Component/s: Replication, Sharding
Affects Version/s: None
Fix Version/s: 3.7.4

Type: Bug Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Spencer Brody (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2018-03-26
Participants:
Linked BF Score: 0

 Description   

Generally speaking atClusterTime readConcern is sent via mongos, which will also include $clusterTime metadata to advance the clock. If, however, an atClusterTime readConcern was received without $clusterTime metadata, or with a $clusterTime less than the atClusterTime value, then the no-op write performed by the read concern machinery might fail to advance the clock, and the read can block forever waiting for the cluster time to advance. Instead of hanging forever, the read should fail.



 Comments   
Comment by Githook User [ 15/Mar/18 ]

Author:

{'email': 'spencer@mongodb.com', 'name': 'Spencer T Brody', 'username': 'stbrody'}

Message: SERVER-33798 Fail atClusterTime reads at times newer than the current cluster time
Branch: master
https://github.com/mongodb/mongo/commit/0abcf8f3cf547327c4dab4aea1ff22e1d75a8db8

Comment by Eric Milkie [ 12/Mar/18 ]

Yes; I changed the summary to match the code review's title.

Comment by Andy Schwerin [ 12/Mar/18 ]

Should the summary say greater instead of less?

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