Exception in queued task: Error: Can't set timers inside simulations

[BudgieInWA]

I am experiencing the following exception when using SubsCache in conjunction with Iron Router:

Exception in queued task: Error: Can't set timers inside simulations
    at withoutInvocation (http://10.1.1.50:3000/packages/meteor.js?43b7958c1598803e94014f27f5f622b0bddc0aaf:434:13)
    at bindAndCatch (http://10.1.1.50:3000/packages/meteor.js?43b7958c1598803e94014f27f5f622b0bddc0aaf:442:33)
    at Object._.extend.setTimeout (http://10.1.1.50:3000/packages/meteor.js?43b7958c1598803e94014f27f5f622b0bddc0aaf:458:23)
    at Object.SubsCache.SubsCache.subscribeFor.cachedSub.delayedStop (http://10.1.1.50:3000/packages/ccorcos_subs-cache.js?6a3225527386ddcfc7167b4226cf4ccde60559c2:165:44)
    at http://10.1.1.50:3000/packages/ccorcos_subs-cache.js?6a3225527386ddcfc7167b4226cf4ccde60559c2:156:30
    at http://10.1.1.50:3000/packages/tracker.js?6d0890939291d9780f7e2607ee3af3e7f98a3d9c:296:31
    at Object.Tracker.nonreactive (http://10.1.1.50:3000/packages/tracker.js?6d0890939291d9780f7e2607ee3af3e7f98a3d9c:593:12)
    at Tracker.Computation.invalidate (http://10.1.1.50:3000/packages/tracker.js?6d0890939291d9780f7e2607ee3af3e7f98a3d9c:295:15)
    at Tracker.Dependency.changed (http://10.1.1.50:3000/packages/tracker.js?6d0890939291d9780f7e2607ee3af3e7f98a3d9c:421:30)
    at http://10.1.1.50:3000/packages/minimongo.js?af9eb9d7447544ca9b839a3dcf7ed2da2209b56c:415:13
debug.js:41

Exception in callback of async function: Error: 

You called wait() after calling ready() inside the same computation tree.

You can fix this problem in two possible ways:

1) Put all of your wait() calls before any ready() calls.
2) Put your ready() call in its own computation with Deps.autorun.
    at Iron.utils.assert (http://10.1.1.50:3000/packages/iron_core.js?d966a1f70c94792fd94c8a155bdbef9bec5e0047:81:11)
    at http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:87:5
    at Array.forEach (native)
    at assertNoInvalidationLoop (http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:86:14)
    at WaitList.wait (http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:125:3)
    at Controller.wait (http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:442:20)
    at eachWait (http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:439:12)
    at Array.forEach (native)
    at Function._.each._.forEach (http://10.1.1.50:3000/packages/underscore.js?0a80a8623e1b40b5df5a05582f288ddd586eaa18:156:11)
    at Controller.wait (http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:438:7)

http://10.1.1.50:3000/packages/ccorcos_subs-cache.js?6a3225527386ddcfc7167b4226cf4ccde60559c2:156:30 corresponds to subsCache.coffee:85.

My Iron Router subscription looks like:

Router.route('/ticket/:_id', {
    name: 'ticketScreen',
    waitOn: function () {
        return [
            singleSubs.subscribe('ticketById', this.params._id),
        ];
    },
    data: function() {
        return Tickets.findOne({_id: this.params._id});
    },
});

and the exception happens when the document is updated from within the page (but not if it's updated somewhere else). For example:

Tickets.update('RjfW8d8Q93MupLXfJ', {$set: {notes:"yolo"}})

[ccorcos]

Honestly, I don't really know what this is about. I tracked it down here, but its pretty odd if you ask me.

#4

I've be straying away from iron router. Its not exactly simple to look inside and figure out why things are going wrong...

[jimmiebtlr]

I'm running into this issue as well, not using iron router.

Seems to me it's likely something to do with latency compensation.

Any ideas that can point me to how to fix this? It almost seems like it may be Meteor.setTimeout throwing any time isSimulation is true. Pure speculation at this point though.

[jimmiebtlr]

There is a Meteor.setTimeout used in the project. I think Meteor tries to be clever and realizes that data generated in a simulation should probably not be used later in time, to avoid potentially having out of date information. I think this package doesn't need to worry about that case, maybe use only non-meteor setTimeout instead?

[convexset]

Any updates on this?

[jimmiebtlr]

Went ahead and and published to

https://atmospherejs.com/jimmiebtlr/subs-cache

[ccorcos]

thanks @jimmiebtlr!