-
Notifications
You must be signed in to change notification settings - Fork 10.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chore: Remove role requirement to use change streams #27281
Conversation
Co-authored-by: Aaron Ogle <geekgonecrazy@users.noreply.github.com>
Codecov Report
@@ Coverage Diff @@
## develop #27281 +/- ##
===========================================
+ Coverage 40.24% 41.25% +1.00%
===========================================
Files 847 819 -28
Lines 18430 17933 -497
Branches 2052 1988 -64
===========================================
- Hits 7417 7398 -19
+ Misses 10727 10247 -480
- Partials 286 288 +2
Flags with carried forward coverage won't be shown. Click here to find out more. |
Just for context before this.. frequently people who start using permissions with mongo but missed this permission start encountering reactivity issues that look like Rocket.Chat is buggy. But then as soon as they added it things started working fine. One common one was connectivity services, but also anything that depended on change stream to populate setting cache. The permission is only needed for something informational that provides little value. So requiring is costing way more than we lose by removing it. IMO for customer experience this is a must for the release. If a release wasn't coming I'd argue for a patch that's how impactful it is. |
Co-authored-by: Aaron Ogle <geekgonecrazy@users.noreply.github.com>
Co-authored-by: Aaron Ogle <geekgonecrazy@users.noreply.github.com>
Proposed changes (including videos or screenshots)
We used to require the
clusterMonitor
role to be able to use Change Streams because we performed aserverStatus
command, to be able to check if the requirements for change streams are met (like using wired tiger for example). But since our minimum MongoDB supported version is now 4.2, and MMAPv1 was removed on this version, there is no need to check that.The new approach is just try to use change streams, if it fails for any reason, fallback to oplog.
If oplog fails as well, we're now halting the process, since it wasn't able to establish a connection for reading real time data, something that is crucial for the application. An additional check was added to make sure
$MONGO_OPLOG_URL
is pointing to thelocal
database.Issue(s)
Closes #20017
Steps to test or reproduce
Further comments