Stagger meteor reload on deploy?


When I deploy my app, it force reloads for all users who have it open. During this force reload I make some calls to a (non-meteor) API server. The stampede of calls crashes my API server for a while.

Is there any way to stagger the meteor reloads during the deploy?


I found an old StackOverflow thread, How can I prevent Meteor hot Reloads while still keeping meteor attempt Reload._onMigrate on every change?, which may get you a little down the rabbit hole.


That’s really interesting! I never knew about a Reload object, nor Autoupdate or LiveUpdate. I don’t see it in the documentation. I wonder if we can somehow use it to prompt the user when a code push is done, saying something like “A new update has been released, click the button in the corner to reload once you’ve finished saving your work.”


Yeah it’s probably not in the documentation. The method used in that SO answer Reload._onMigrate starts with an underscore implying it’s not really meant to be public. So there might be a solution, but I’m guessing it won’t be officially Meteor supported. Sounds like a good candidate for an atmosphere package as this is an edgy use case, but perhaps common enough that a few people run into it.


Forced reloads are very disrespectful to users, especially when the user is in the process of doing a financial transaction, so any alternative to forced reloads are very welcome.


I figured out how to prevent auto-reload. Just make sure this is executed on the client at client startup:

import { Reload } from 'meteor/reload';
import store from '/imports/redux/store';
import { reloadPending } from '/imports/redux/actions';

Reload._onMigrate(function (retry) {
  return false;

I’m just dispatching a Redux action which sets a flag in the app state that indicates a code push is ready. So I can read that and add a button or something in the top left of my app saying “Code update available - click to reload.” And then when the user clicks that reload button:


I couldn’t get any of the Reload package’s retry function or migration stuff working at all. So I’m just doing a manual reload which works just as well.


When your server also reloads there is a balance because you can hold the old version in the client but your server logic might change under it’s feet. Statelessness is an important factor here, if after the reload the app is in exactly the same state including the user inputs it might be one of the better ways of doing it.

If the business logic changed the intent of the user (which doesn’t happen too often on the same url) it might be better to abort the transaction. You can do that by manually coding that step as a migration. If it’s just a new version with improved error handling, interface changes or unrelated parts to the users intent you may just proceed without any issues in most cases.