Publications/Mongo only half-working in production


Hello! I’ve been in the throes of developing my first Meteor app the past few weeks, and am working on finally getting it into production. I’m hosting on Google Compute Engine. I followed the basics of this guide to get my Compute Engine instance and Mongo disk set up, and after some tinkering it got running and I can now access my app at the instance’s ip address. Yay!

Since it seems to be running, the issue I’m currently having is an odd one. I can sign in with the stock Accounts-ui form and navigate to different pages, but some of the pages (not all) are stuck indefinitely on the Iron Router’s “loading template”. One call I can confirm isn’t working is Meteor.users.findOne(the_user_id); (called from inside a Meteor.method()), although find() calls on my custom collections seem to not always work either.

Is there a configuration detail that I missed somewhere? I’m a noob when it comes to infrastructure so it’s entirely possible, I’m just not sure where to look. Per the guide, I created a Compute engine instance and a separate persistent disk for Mongo, and in the instance’s terminal I tried setting export MONGO_URL='<other_variations_of_urls_that_I_thought_might_work> to no avail.

I’d really appreciate any help or suggestions on getting my app up and running. Thanks!

EDIT: I should note, everything works beautifully when I run the app on my local machine. The issue has only arisen now that it’s bundled and hosted on a server.


I’m still working on confirming this (been a long few days…), but it appears that the publications that don’t work are the ones that I pass a query operator in for. Routes that subscribe to publications that return MyCollection.find({});, or return MyCollection.find({}, sortOptions); are great, while the publications I have that return MyCollection.find({author : {$eq : username}});, or return MyCollection.find({_id : itemId}); or anything to that effect seem to get stuck, and the Router’s “loading” template spins forever.

I’ve no clue why that would be the case, but need to keep digging. Any insights?

(edit: I also followed the classic IT trope and shutdown and restarted my Compute Engine instance, still no luck.)


Sorry to be annoying - I did some more comprehensive console.logging and mostly confirmed the above - in my Meteor.publish functions, whenever I pass a query into find() that isn’t querying by _id (i.e. {_id: userId}, then no documents are published and the router’s waitOn runs indefinitely. Querying by _id returns the expected documents, as does not passing in any query parameter (i.e. find({})).

Not sure if it’s relevant, but my routes are of the following format:

    layoutTemplate: 'layout',
    loadingTemplate: 'loading',
    notFoundTemplate: 'not_found',
    trackPageView: true,
    waitOn: function() {
        return [Meteor.subscribe('notifications')];


SomePageController = RouteController.extend({
template: 'someTemplate',
subscriptions: function() {
    this.somePageSub = [
        Meteor.subscribe('posts', decodeURI(this.params.username)),
data: function() {
    return {
            posts: this.posts(),

…which I’m publishing with

Meteor.publish('posts', function(username) {
    check(username, String);
    return Posts.find({author : {$eq : username}});

^the above publish function works on development but returns an empty cursor on production, whereas if it were to instead return Posts.find({}); it would return a cursor to all posts.


if it returned empty cursor, it would not show spinner anymore.
More likely it would not return at all.
And that sounds strange.

Have you tried querying in mongodb itself ?


Hi @shock, I might not be completely up on my terminology. By “empty cursor” I mean that when I call Posts.find({}).fetch(); from my web browser, it’ll return an empty array if the publish function has a query parameter (other than _id), and it’ll return an array of the objects I’d expect if it has no query parameter (or is only querying by _id). There are objects that the first publish function should be returning (i.e. that fetch() array shouldn’t actually be empty), so I suspect that something is causing the publish function to not return at all.


@alexpete which version of MongoDB have you installed?


@hellstad hmm, excellent question. On the compute instance I have running it appears to be v2.4.14. I’m not sure how to check which version I have locally, buy I read somewhere it ought to be either 2.6 or 3.0, so that may very well be the discrepancy. Do you know how to check my local mongo version that’s installed with Meteor so I can upgrade the server instance to the same version?


you are using the $eq operator (may be unnecessarily), which AFAIK is only available in Mongo 3.0. So your Mongo is probably crashing your publications. Just install MongoDB 3.0 :smile:


@hellstad the $eq operator seems to have been the culprit! Thanks for that, I never would have suspected the mongo versions to have a discrepancy.

For the time being just removing those operators will work, and although I should probably upgrade Mongo I’m afraid to. From everything I’ve read so far it seems like a really non- noob-friendly process, and I’m uncertain about how replacing the mongo binary files on the server will affect the attached persistent disk.