It’s common to run into difficult-to-predict situations where a user will accidentally filter large numbers of records on a non-indexed field, especially if users are given options to sort and filter their data. And, of course, this is a problem for any backend, including SQL-based ones.
In looking into solutions for this, I came across cursor.maxTimeMS() (mongosh method) - Database Manual - MongoDB Docs which seems to give you the option to set a per-query timeout on how long a Mongo query can run. If the timeout hits, it errors out as if the operation was killed on the server. It would be incredibly elegant if we could have a find option that sets this on Mongo queries - it would be a single-line change to prevent any subscription from overloading the server. Sadly, there are literally zero Google queries for “maxTimeMS +meteor” at the time I write this.
As someone new to Meteor internals - is it possible to write this as a package that would affect the initial fetch? Or would this be more something that would need to override low-level Meteor behavior?
2 Likes
I know it’s an old topic. As it hasn’t been answered, I want to resurrect it. Does anyone have a solution for that, and what could be an acceptable timeout value? Something like that
function applyGlobalMaxTimeMS(collection) {
const raw = collection.rawCollection();
const originalFind = raw.find.bind(raw);
raw.find = function (...args) {
const cursor = originalFind(...args);
cursor.maxTimeMS(10000);
return cursor;
};
}
Meteor.startup(() => {
applyGlobalMaxTimeMS(MyCollection);
});
Does Meteor have a default value?
I know meteor accepts the option on query level but is it possible to set it globaly.
Any problem with overriding the original method as you have done above? Short of a global variable, that looks like a good option
I’m always afraid when using meteor.startup. I always worry that the order of these might get mixed up with an import error. I’m especially curious if someone has tested this type of code in production and I’m curious about their experiences.
Is 10000ms too low or 30000 too high? Of course, it will depend on the load and server conditions, but shouldn’t there be a default interrupt here? Shouldn’t there be a similar value in meteor.methods?
Not related to the default max query time, but we have overridden/overloaded several default Meteor functions both in client and server, especially if we wanted to apply our way of doing things. This also shielded us from many changes throughout the years that should have required us to change all the places where we used that function, but instead, we only needed to update the override.
If you use APM, try to see what is the longest you’ve ever waited on the DB. If you don’t, use APM :). This might help you to decide on your wait time.
Startup …
I override most of the DB functions. I import a file with all my overrides at the top of server/main.js. This comes before startup.
How about this … just an idea, not tested. Redeclare the prototype of your find method with an altered cursor.
Mongo.Collection.prototype.find = function (query = {}, options = {}, cursorOptions = {}) {
// inherit all args from the original find()
// your Collection = this
// your cursor = this.find(qury, options)
// alter the cursor
// return the cursor
}
Of course I’m using APM 
One of the most loved features of Meteor. Thanks to Arunoda and Zodern 
I have been working on a simple boilerplate project and trying to find a proper solution to add a timeout feature. Sometimes, a very simple find query takes longer than expected, and a simple page refresh makes it faster. In these cases, a timeout check will relax the server.
I prefer init file as https://github.com/guncebektas/fireball/blob/main/server/init.js instead of the startup wrapper. Also, adding it into a baseRepository like https://github.com/guncebektas/fireball/blob/main/imports/modules/shared/repository/baseRepository.js, this can be a nice solution. I don’t like over-engineering and need a simple solution. Just wonder what others are doing. @rjdavid, what kind of functions have you overridden, and why?
And most of the time, the refresh adds more load to the server.
Of course, but we can’t prevent users’ refresh intent when things get stuck.