Is there a standard mechanism in Meteor to stop/pause some/all method calls? I am interested in making sure custom asynchronous DB migration logic (run as Meteor.startup(async (...) => { ... })) is completed before any client can start interacting with the system. Maybe what I am trying to achieve is dumb 
?
i don’t think there’s anything built in - you could fairly easily make a wrapper around meteor methods though (or patch Meteor.method), then you could use either a local lock or redis lock (or anything else really) to ensure that method calls wait during startup.
If you are specifically interested in preventing DB modification, you could also use transactions for your migrations
Indeed, I am currently experimenting with transactions to make the DB migrations rock solid. I am just worried that given the scope of these migrations (sometimes scanning entire collections), it may be more prudent to disable at least data writes during the migrations. I have actually no idea what makes sense.
I wouldn’t call it dumb. DB migrations are rarely (if ever) straightforward no matter what stack is used. Especially when it comes to migrations where users are actively adding DB records, which sounds like what you’re trying to guard against.
If I understand it correctly, it seems as though global or environment variables could help. Within Meteor.startup() you could set one to something your Methods could look for. i.e. process.env.allowDbWrites = false
Then in your methods, you could do what @znewsham suggested, which is to wrap something around Meteor Methods or patch it such that the methods can execute the DB write only if process.env.allowDbWrites is true.
Once you’re .startup() async call is done, you’d set process.env.allowDbWrites to true so the Methods can do their thing.
1 Like
Thanks. I had not thought about using env variables. Does it provide anything more than say a global variable (not tied to env, just a regular JavaScript variable) with setter and getter?
To improve the user experience, I was thinking to add a special document to a special collection so that users can subscribe to the current state of the system (‘booting’, ‘migrating’, ‘ready’, for instance).
Not really, global variables can work just as well as env variables. You don’t really need getter and setter either. Just simple assignments like I wrote above should do the trick.