Match error: Expected number, got undefined

[sergical]

I have lib/collections.js

Transfers = new Meteor.Collection('transfers');
Pages = new Meteor.Pagination(Transfers, {
  perPage: 5,
  sort: {
    date: -1
  },
  templateName: 'listTransfers'
});

... some Transfers.allow({})

server/publications.js

Meteor.publish('transfers', function() {
  // return Transfers.find();
  if (this.userId) {
    return Transfers.find({userId: this.userId});
  } else {
    this.ready();
  }
});

listTransfers.html

<template name="listTransfers">
// some html
  {{> pages}}
  {{> pagesNav}}
</template>

I am getting the following error

Exception from sub yM3hezX7b6g6wFMn3 Error: Match error: Expected number, got undefined
I20150107-21:32:16.542(-5)?     at checkSubtree (packages/check/match.js:159:1)
I20150107-21:32:16.542(-5)?     at check (packages/check/match.js:32:1)
I20150107-21:32:16.543(-5)?     at Pages.__Pages.Pages.publish (packages/alethes:pages/lib/pages.coffee:477:5)
I20150107-21:32:16.543(-5)?     at [object Object]._handler (packages/alethes:pages/lib/pages.coffee:136:20)
I20150107-21:32:16.543(-5)?     at maybeAuditArgumentChecks (packages/ddp/livedata_server.js:1599:1)
I20150107-21:32:16.544(-5)?     at [object Object]._.extend._runHandler (packages/ddp/livedata_server.js:943:1)
I20150107-21:32:16.544(-5)?     at [object Object].subscriptionProto._runHandler (packages/meteorhacks:kadira/lib/hijack/wrap_subscription.js:12:1)
I20150107-21:32:16.545(-5)?     at [object Object]._.extend._startSubscription (packages/ddp/livedata_server.js:769:1)
I20150107-21:32:16.545(-5)?     at [object Object]._.extend.protocol_handlers.sub (packages/ddp/livedata_server.js:582:1)
I20150107-21:32:16.545(-5)?     at packages/meteorhacks:kadira/lib/hijack/wrap_session.js:69:1
I20150107-21:32:16.558(-5)? Sanitized and reported to the client as: Match failed [400]

[lc3t35]

+1 Same for me !

[ivankravchenko]

+1
same error at #111

[sergical]

hopefully we can see a fix soon 😄

[advany]

any fix? same problem

[kalarani]

I had the same problem. There was another message ("Ignoring duplicate publish named 'tasks'") along with this one. Removing the publication for 'tasks' solved this issue for me.

[rclai]

I get the same error message, but my table seems to still be working fine. However, instead of saying Match error: Expected number, got undefined it says Match error: Expected number, got string

[rclai]

For anyone interested I created a patch to get rid of the error here.

[rclai]

Using my DDP inspector, I saw the root problem:

Initially Pages is sending this subscription with the first parameter as a String. Also I have no idea what that '18963' number represents. It's not the number of documents in my collection.

Object {
   msg: "sub", 
   id: "zDWQYwPeHCZmjPYKD", 
   name: "purchaseOrders",  // my collection name
   params: Array[2]
       [
          0: "18963"
          1: undefined
       ]
}

[advany]

Rclai! you rock :) Hope this gets merged back in soon

[advany]

to bad this didn't got included in the latest version

[rclai]

Did he fix the issue in his new update, or is the issue still there?

[vladholubiev]

+1
Faced this issue just now. Any workaround?

[rclai]

I guess you can try and use my patch I mentioned above.

[vladholubiev]

@rclai I am new to Meteor and not sure what to do with your code snippet.

[rclai]

In your app root folder, create a packages folder, and inside of that folder, git clone this repo, you will notice your app start rebuilding, that means that Meteor will now look at that folder as the new location where the alethes:pages package lives. Then go to my patch, and apply the code in my patch into the lib/pages.coffee file around line 498. Does that make sense?

[vladholubiev]

@rclai, definetly yes. Thank you, finally figered it out. Why don't you make that patch as pull request?

[rclai]

Okay cool. I didn't want to make it a pull request because it's a patch job and thought that @alethes might have a more appropriate fix unless he thinks it's appropriate enough and asks to make it a pull request.

[alethes]

It might have had something to do with defining the publication with the same name as one defined automatically by Pages. In the recent versions, the default publication name is "pages_{{collection_name}}". Previously, it was just the collection name. Usually, there's no need to define a separate publication on the paginated collection, unless you want to use it outside Pages.