Multiple containers on app, triggers ObserveChanges twice

Hey fellow devs,

I’m working on an app where we use ObserveChanges to see if a user add a comment to a booking.

It’s been working fine, but now upgraded out app in galaxy to run with 2 conainers instead of 1, which results in that each container ObserveChanges to the booking and therefore it triggers the event (sending notifications to users) twice.

Anyone had similar problems or know how to fix this? For now we have downgraded to 1 container again, but we would like to have multiple for stability.


Im not sure I understood correctly, but im assuming that you are sending a push o email notification to a user on the observe change

If that’s true, I don’t think that is not a good use case for observe changes. It will be better to put your code in to a collection hook or in the createComment method.

Yes almost.

So when a new comment is added, I’m setting a key inside the comment called “sendNotifications: True”. (it’s not all comments that should fire the notification)

Then the observeChanges is looking for booking comments where the sendNotification is true has been added. If that’s the case, it should sent an e-mail and sms in this case and afterwards it will set the sendNotification to the time it has been sent.

Another point is also that the reason i chose to use the ObserveChanges, is that comments are added from different meteor apps but with the same mongoDB. So example the user has one app, and the restaurants which manage the booking has their own platform.

Would this still be possible with a collectionHook?

The collection hook will need to be declared or attached on all the servers you are using, but if you are sharing the “api” code between all these apps that is already done.

You could pick one your containers to be the “primary”, and have only the primary server run the observeChanges

1 Like

Roger that, thanks for your help! :slight_smile:

Hey Veered,

Thanks for the reply! Can you guide me a bit more here? Where do i set one of the containers to be the primary? And do i somehow need to add some code to the app to tell it only to run the observeChanges on the primary?

Easiest way is to set an environment variables on one of the containers like IS_PRIMARY and then access it from within the server using process.env.IS_PRIMARY. Then you’ll have to make sure to only run the observes when IS_PRIMARY is true.

I see… The problem is tho at the containers use the same settings file? I’m guessing I should set IS_PRIMARY: "container-name" in the settings file, and then check for that container around the code. But how can I from Meteor code check if it’s the right container?

Something like IS_PRIMARY === containerName

Hope it make sense, thanks for the help!

If the containers have different names then the approach you mention should work

Yeah, I figured out a way to get the container ID. Which can be found here:

The env var GALAXY_CONTAINER_ID was what I’m looking for. Though this led me to a new problem that every time I redeploy or the container crash for some reason it gives me a new container and therefore i can’t set the IS_PRIMARY in meteor.settings if the name will change in the future…

So the search continues. :slight_smile:

Hi Emil, did you figure out a solution? I’m having a similar issue (in our case it’s timers that are running twice).

Hey Bartoftutourmundi,

Not yet, i wrote a bit with the galaxy team just confirmed that it was not a good option since it reset the ID everytime you deploy again.

Our solution for now was to scale down to 1 container and then scale that container up. But we want to find a better solution, but I don’t have much time to look into it right now.

Another idea was to deploy another “App” that only handles these kind of things in the background so the load from the users and such won’t effect it at all. And then just have 1 container on galaxy to handle it behind the scene, etc. Observe, Cronjobs, timers.

If you find a good solution please let me know :slight_smile:
Best regards!

Thanks Emil, I ended up taking the “other app” route (basically the same app with one environment variable changed and no public URL configured).