MONGO doc with array - Having issues with Sort ASC vs DESC sort - "falsey" error

help
1

HI,

I am sorting a collection both in the publication and on the client,

my code is identical:

SomeCollection.find({field1:"someval"},{sort:{sortVal:1},limit:10}); This works.

However when I chance the value to descending:

SomeCollection.find({field1:"someval"},{sort:{sortVal:-1},limit:10}); I get this error on the client

Exception from Tracker recompute function:
4fbb157….js?meteor_js_resource=true:3 Error: {{#each}} currently only accepts arrays, cursors or falsey values.

Any ideas pls?

Update: some more info on the error:

Exception in queued task: Error: {{#each}} currently only accepts arrays, cursors or falsey values.
    at o (https://a.buzzy.buzz/48150624d89ccc80e05c24498fa367609400db5f.js?meteor_js_resource=true:86:995)
    at https://a.buzzy.buzz/48150624d89ccc80e05c24498fa367609400db5f.js?meteor_js_resource=true:86:755
    at Object.o.nonreactive (https://a.buzzy.buzz/48150624d89ccc80e05c24498fa367609400db5f.js?meteor_js_resource=true:34:4471)
    at https://a.buzzy.buzz/48150624d89ccc80e05c24498fa367609400db5f.js?meteor_js_resource=true:86:590
    at o.Computation._compute (https://a.buzzy.buzz/48150624d89ccc80e05c24498fa367609400db5f.js?meteor_js_resource=true:34:2427)
    at new o.Computation (https://a.buzzy.buzz/48150624d89ccc80e05c24498fa367609400db5f.js?meteor_js_resource=true:34:1351)
    at Object.o.autorun (https://a.buzzy.buzz/48150624d89ccc80e05c24498fa367609400db5f.js?meteor_js_resource=true:34:4290)
    at Object.observe (https://a.buzzy.buzz/48150624d89ccc80e05c24498fa367609400db5f.js?meteor_js_resource=true:86:559)
    at .<anonymous> (https://a.buzzy.buzz/48150624d89ccc80e05c24498fa367609400db5f.js?meteor_js_resource=true:90:28323)
    at n (https://a.buzzy.buzz/48150624d89ccc80e05c24498fa367609400db5f.js?meteor_js_resource=true:90:19914)
4815062….js?meteor_js_resource=true:3 Exception from Tracker recompute function:
4815062….js?meteor_js_resource=true:3 Error: Bad index in range.getMember: 9
    at t.getMember (4815062….js?meteor_js_resource=true:90)
    at 4815062….js?meteor_js_resource=true:90
    at Object.o.nonreactive (4815062….js?meteor_js_resource=true:34)
    at Object.changedAt (4815062….js?meteor_js_resource=true:90)
    at 4815062….js?meteor_js_resource=true:86
    at Function.A.each.A.forEach (4815062….js?meteor_js_resource=true:1)
    at l (4815062….js?meteor_js_resource=true:86)
    at 4815062….js?meteor_js_resource=true:86
    at Object.o.nonreactive (4815062….js?meteor_js_resource=true:34)
    at 4815062….js?meteor_js_resource=true:86
2

What do you see when you console.log the results of your client side find?

console.log(
  SomeCollection.find({field1:"someval"},{sort:{sortVal:-1},limit:10}).fetch()
);
3

@hwillson thanks for the response.

Yep, I had done that call both in the browser console, in the helper and in the publication, in all instances it seems to show the correct collection results.

I should add, I cannot replicate the issue

a) locally - ie this only happens in production
b) it only happens in production in one instance - I have the code running with Parent Record A, but Parent record B the bug shows up. I can replicate the error consistently on “Parent B” by changing the ASC/DESC order… .ie it only happens on descending… ascending works fine.

I have tried placing Template.instance().subscriptionsReady() checks in the templates and the helpers…but it does not seem to help. I tried deleting and recreating the indices too. No luck.

I am using https://github.com/englue/meteor-publish-composite for my collections… this works with everything else… again it’s this one bit of code that seems to be dying in this one instance.

The error message above is not every helpful to me… or I am not good at debugging it to get to the exact line of code it’s dying on. I divided and conquered to isolate the line of code… which ends up as the “each” call to the publication… but I think I just eliminated the issue vs actually isolated the line of code.

It seems like a latency issue… but I have much larger datasets where the issue does not apply.

I did a .explain() on the mongo query on the ascending vs descending … and they both seemed similar … I was not really sure what I was looking for but I could not see anything there that jumped out at me as an issue.

Any ideas welcome.

4

More info… I think I have found the cause. The Parent B had a bunch of child records, where each was storing an array of file data (not the actual blobs) but just the meta data. Some of this could be quite large (eg all EXIF data).

When I delete this column, the problem goes away. A while ago I’ld moved to a normalized 1:M relationship (not using the array) which avoids the issue, which is why I was not seeing this issue today… however some of the legacy content used the old approach.

Is there a limit on the amount of data that could/should be stored in an array on a Mongo doc with Meteor? ie sometimes its easier to denormalize the data to try and get some performance improvements.

Does this sounds like it would cause the problem?

Any comments/recommendations pls?