[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: |
|
||||
| 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: |
| 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? |