Multiple Subscriptions Fields Problem

I’ve read every post on this I can find and am stumped as to why my code is failing. Apologize if I’m being thick-headed, but I think I’m doing it right. However, I don’t get all of the fields published when a previous publish has limited the fields.

Why is my subscription to the single record not adding the ‘files’ field?


Meteor.publish('turnovers_no_files', function(pid)
    return Turnovers.find({'project':pid}, {fields: {'files':0}});
Meteor.publish('turnover', function(tid) {
    return Turnovers.find({'_id':tid});


Template.turnovers.onCreated(function() {
    var self = this;

    self.turnover = new ReactiveVar(null);
    self.tid      = new ReactiveVar(null);

    var pid = Session.get('current_project_id');

    self.autorun(function() {
        self.subscribe('turnovers_no_files', pid);

        var t_sub = self.subscribe('turnover', self.tid.get());
        if (t_sub.ready()) {
            if (self.tid.get()) {
                var t = Turnovers.findOne({'_id':self.tid.get()});
                console.log('"turnover" subscription is ready.')
            } else {
                console.log('turnover not yet selected');
        } else {
            console.log('"turnover" subscription not ready.');

    'click .turnover-nav-link': function(event, template) {

        var tid = $("my-data");

Console (no “files” field?)

> Turnovers.find().fetch()     // Only one record in the DB
    _id: "NGfEFbCn67KHGnFBk"
    date: "2015_10_06"
    ingested: false
    name: "MyTurnover_01"

Maybe you should have a look at your publish function (missing pid variable in your function définition ?)

1 Like

Sorry, that was just a copy/paste issue. I’ve fixed it in the example.

Aloha - a couple of things to consider here that might help:

  1. From the Meteor subscribe docs: “If more than one subscription sends conflicting values for a field (same collection name, document ID, and field name), then the value on the client will be one of the published values, chosen arbitrarily.”

  2. The way MergeBox works.

And just to add relating to #1, here’s what this looks like in the Meteor source:

sendChanged: function (collectionName, id, fields) {
  var self = this;
  if (_.isEmpty(fields))

  if (self._isSending) {
      msg: "changed",
      collection: collectionName,
      id: id,
      fields: fields

This is being called for both of your subscriptions, so your fields value for the “turnovers_no_files” subscription is likely the one being chosen.

By that logic, if I don’t specifically exclude the files field, then I should be ok, right? It still doesn’t seem to work. I thought I read something about meteor using a union of the fields in the collision.

Meteor.publish('turnovers_no_files', function(pid) {
    return Turnovers.find({'project':pid}, {fields: {'name':1,'date':1,'ingested':1}});
Meteor.publish('turnover', function(tid) {
    return Turnovers.find({'_id':tid});

I don’t see how your subscription code would get the right turnover object. Aren’t you passing in a pid instead of a tid?

Thanks for catching that and I was optimistic that was the issue! But, alas, still no files field. Should this work or are my expectations not correct?

I think it will be very hard to diagnose the problem without having an app to run. If you can post a small app to GitHub, I can check it out!

DAAAAAHHH, that WAS the issue. When I fixed what you noted I forgot to add the .get() to the self.tid.get() change. So, this works now! I’ve updated the OP so it is a working example.

Thank you guys so much for taking the time to help me. Love this place.

1 Like

I know this is a very old thread but seems like this problem is still present?
From the current docs:

Currently, when multiple subscriptions publish the same document only the top level fields are compared during the merge. This means that if the documents include different sub-fields of the same top level field, not all of them will be available on the client. We hope to lift this restriction in a future release. (Source)

Is there any way around this?
This has to be a pretty common problem, no?