Another LiveData Error #12
Comments
|
This bug was seems to be fixed. see: #9 |
|
I just pulled the new version and deployed again - error is not resolved: |
|
Okay. Can you send me some code where I can reproduce this error. On Thursday, January 16, 2014, Ahmed Hassan notifications@github.com
Arunoda Susiripala @arunoda http://twitter.com/arunoda |
|
Hey @arunoda i am sorry i tried to clean up the project and remove company code but i could not reproduce the error on a minimum version of the project. Maybe the FastRender log could help you? The songs collection is fast rendered inside the iron routers waitOn |
|
That's fine. Send the HTML got from view source too. On Thursday, January 16, 2014, Ahmed Hassan notifications@github.com
Arunoda Susiripala @arunoda http://twitter.com/arunoda |
|
The issue here is because, there are 2 subscriptions made for the Song publication. One is outside IR and one is inside IR. BTW: The subscription made inside the IR did not send any data. Anyway, I can work on a fix. |
|
Great thank you for your effort |
|
Ah, I think this explains some of my issues too. Is this documented clearly? It's definitely something that can come up in cases like mine, where I migrated to Iron Router specifically so I could use FastRender. |
|
Hey. I got it. But migrating to IR is not bad choice anyway :D On Thursday, February 13, 2014, Kevin Kaland notifications@github.com
Arunoda Susiripala @arunoda http://twitter.com/arunoda |
|
Yeah, I am glad I did. It's so cool :) Thanks for working on the hard stuff and your help today! |
|
Hi Arunoda, Was there a fix implemented for this issue? We are also getting this error in FR and this error is currently breaking the spiderable package whenever the site is rendered through phantomjs. |
|
I can confirm that I just ran into this as well at login and have to remove fast-render as a temporary workaround. I am using the latest fast-render version. |
|
What's the meteor version you are using? If I can have a some minimal repo. On Tuesday, May 27, 2014, landland notifications@github.com wrote:
Arunoda Susiripala @arunoda http://twitter.com/arunoda |
|
Release 0.8.1.3 Let me see if it can be reproduced with a minimal repo. |
|
Cool. Thanks. On Tuesday, May 27, 2014, landland notifications@github.com wrote:
Arunoda Susiripala @arunoda http://twitter.com/arunoda |
|
Ok, I was able to reproduce the error message. What I wasn't able to reproduce was the fact that I can't login. I think it has to do with an appcache conflict, but I haven't been able to dig into it further. Anyway, you can find repo here: Sometimes you see the message right away and sometimes not. If not, just register a user, logout/login and go back to / a bunch of times. That did it for me. |
|
Okay. Thanks. Arunoda Susiripala @arunoda http://twitter.com/arunoda On Wed, May 28, 2014 at 12:13 AM, landland notifications@github.com wrote:
|
|
Okay. I found the issue. This is with the null publications (autopublish, loggedIn user). |
|
Can you please use version |
|
I still see this issue using |
|
Okay. Let me see, what I can do. Arunoda Susiripala @arunoda http://twitter.com/arunoda On Thu, May 29, 2014 at 9:41 PM, landland notifications@github.com wrote:
|
|
I also get this exact same error: the logout button disappears if the page is loaded while the user is logged in. Regardless of whether the user is logged in, if a page is loaded, the server outputs the error "Publish handler for null sent no ready signal". edit: |
|
Can you please try this branch: https://github.com/arunoda/meteor-fast-render/tree/fix-49 I've made a fix. |
|
Released a new version: v0.2.6 |
|
Thanks, this does indeed fix the issue for me. |
|
v0.2.6 works for me. thanks Arunoda. |
|
Awesome. On Sunday, June 8, 2014, landland notifications@github.com wrote:
Arunoda Susiripala @arunoda http://twitter.com/arunoda |
|
i have the latest fast-render version(0.2.8) installed, i got: from my meteor app browser console, i don't even sure that this is related to fast-render, i just found this issue thread! |
|
I get the same error as pajooh, don't know if it's fastRender related either. |
|
It's definitely related to MongoDB's ObjectId. If you create documents inside Meteor, string ids are created. They play nicely with Fast Render. However, native drivers create the ObjectId, which somehow causes this issue. Perhaps it can be fixed easily, but for now to prevent this error you should avoid creating documents outside of Meteor without providing the _id field. If you already have such documents, consider backing up your collection and using something like: in your MongoDB shell. Set |
|
I see this error too. It seems to be related to object IDs, but I'm generating the object IDs in meteor (not externally) and I take their hex string I don't know if it actually damages the web page (doesn't seem like it does) but anyway having errors in the console isn't nice... Versions I use: |
|
I fixed this with version 2.0 of FR. |
|
OK thanks @arunoda just tested with |
|
Great. Arunoda Susiripala @arunoda http://twitter.com/arunoda On Wed, Nov 12, 2014 at 1:57 PM, Ran Tavory notifications@github.com
|
|
Had the same issue with ObjectIds created outside of meteor (imported my documents using MongoImport), and |
kadirahq/fast-render#12 due to ObjectIds created outside of Meteor (on the command line with meteorImport
|
Great. I have fixed couple of many bugs and looking to release 2.0 this
|
|
any updates here? this issue completely prevents me from using fast-render for my app. Why? This is a meteor 1.0.X app with iron-router, spiderable and fast-render (and other stuff): http://newsfisher.io/article/BLbe8Q3o7nDmYg6cH . The page works fine, but ontop of the generated HTML (with ?escpaed_fragment= as parameter) stands the problematic string. The issue gets even more problematic when you click the "facebook share"-button of the AddThis toolbar, the article description is the error code. This is a running real app, so please drop a note when you viewed this @arunoda, so I can disable fast-render again. Fast-render's version is meteorhacks:fast-render@2.1.6. EDIT: the issue was the following: I tracked the page impression for a given article in the template's rendered callback. solved it by moving the code to a server method. I'll let this here just in case this comes up again. |
|
Related issue: #80 |
|
I'm getting I'm using fast-render as a dependency in a package, which calls If user is logged in and refreshes, the error doesn't occur. If use is not logged in I get the above error printed in the server console 4 times each time the client refreshes. |
|
Actually, you've created a publication(probably null) and it didn't call this.ready() within 500 millis. Generally, This happens when a publication takes more than 500 ms to complete. |
|
Thanks @arunoda, I found the problem. I do think the warning is a giving false positive though. Old version, casing warning: New version, warning doesn't occur: I do have some other named publications (not |
|
Actually from a publication you must return a cursor. Otherwise sub is So, if there is no cursor, you need to send an empty array or call We check for null as well. But you should not send null.
|
|
Okay, thanks for the info! |
|
I recently upgraded to Meteor 1.1 and this issue has started happening again. Is it just me? |
|
Same for me! |
|
Getting this too with 1.1 - need to start digging into my publications and find out where I'm not properly returning a cursor. |
|
I nailed down the problem to a null publication (Meteor.publish(null.....). Adding this.ready() in it fixed it. |
|
I found my bad publication as well -- the issue was with how I'm using Andrew Mao aka Mizzao's userstatus plugin. It's been a while since I implemented it, but I had some client and server-side javascript files I created when I laid it down (0.6.4 now). I changed the publication javascript to publish a dedicated name instead of null and updated one of my client javascript files to subscribe to that publication. Problem solved, now I'm pushing 1.1 to my production servers. I was able to narrow it down by turning on mongo profiling and looking at logs. |
|
Same problem here |
|
My problem was with the okgrow:analytics package. It had a null publication that wasn't calling this.ready() when there was no user logged in. |
|
I'm having this issue in production only, but all of my publications return cursors. I am using the okgrow:analytics package as well @elie222. Is it possible to keep that package, but still use fast-render? I removed fast-render for now, but my app runs smoother with it. |
|
It should work with okgrow:analytics now. I think I made a pull request to fix the null publication problem. I do use both packages together |
|
Faced this issue too, in particular, in very fast networks (intranet) and very fast computers (in slower networks/computers happened rarely). I solved it by simply catching the exception, assuming that if the exception occurred, the subscription got ready before fast-render got to load its payload, and therefore fast-render procedures are redundant for that page load. |
I am getting an error when using fast-renderer the error seems to happen after server restart. I traced the error to the following Exception from Meteor:
Error
packeges/mongo-livedata/collection.js - line 127
After removing fast renderer it worked as it should. It seems that this error was caused on login. And maybe because of logintokens that where saved locally or something similar.
I was using meteor 0.7.0.1 - please advice me with more information to support you finding the bug.
The text was updated successfully, but these errors were encountered: