[SERVER-63470] Relax maximum time for mongos cache invalidation propagation Created: 09/Feb/22  Updated: 29/Oct/23  Resolved: 04/May/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Varun Ravichandran Assignee: Varun Ravichandran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Sprint: Security 2022-02-21, Security 2022-05-02, Security 2022-05-16
Participants:
Linked BF Score: 15

 Description   

The mongos_cache_invalidation.js test checks to see whether mongoses in a sharded cluster invalidate their user caches after various UMCs are run. It enforces that the invalidation must occur within 10 seconds, while each mongos polls the config server for user cache generation changes every 5 seconds. In order to test for invalidation, the test tries running update commands as the user whose privileges have been changed and expects to see the update fail after at most 10 seconds.

This works the vast majority of the time, but occasionally the update command takes longer than expected (6-7 seconds). This is enough to run out the clock even if the cache is invalidated during the update. 

In order to mitigate the odds of this happening, we should increase the time the test tries to assert the propagation for. Alternatively, the test could also sleep for a few seconds before the updates start to increase the odds of the invalidation occurring before the update commands start.



 Comments   
Comment by Githook User [ 04/May/22 ]

Author:

{'name': 'Varun Ravichandran', 'email': 'varun.ravichandran@mongodb.com', 'username': 'varunravi98'}

Message: SERVER-63470: Add sleep calls before checking for cache invalidation in mongos_cache_invalidation.js
Branch: master
https://github.com/mongodb/mongo/commit/05c1ac1d57c24cb79eeecec868b0db65bfd02683

Generated at Thu Feb 08 05:57:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.