Derby 0.5.7: "Uncaught Error: Server and client page renders do not match"

[aommm]

OS: Win8 Derby: 0.5.7 Node: 0.10.12 Redis: 2.6.12 MongoDB: 2.2.2

I recently tried to port a project to derby 0.5.7, but ran into lots of problems. I then created an example app to examine how the new version behaves in various circumstances, and ran into a problem immediately.

I created the example app using "new derby test", and when I now try to run it I receive the error "Uncaught Error: Server and client page renders do not match".

The app doesn't crash, but it behaves weirdly. For instance, fetches/subscribes taking place in a route during serverside render returns 'undefined' for each object found, but when I navigate to another page and back again (thus triggering a clientside render) , the fetch/subscribe works as expected.

I assume this behaviour is caused by the previously mentioned error, but thought it worth pointing out just in case.

[lefnire]

To my knowledge, this is caused most often when performing model writes on the server, asynchronously before calling page.render(): https://gist.github.com/lefnire/5959027

[aommm]

I see. It's weird that I receive the error even though no writes are performed in the default route. It simply contains "page.render('home');". Confirmed this bug on my second windows machine as well, might be windows-specific?

[aommm]

Update: 0.5.9 fixed the problem for my main project, but the blank project still reports that it's out of sync.

Another weird thing: whenever I examine my database in godbox, all I see are white lines without content. This isn't causing me any trouble as far as I know, but it's a little unsettling nonetheless.

[nateps]

This error can be the result of many things, since it simply means that the HTML rendered on the server was not the same as the HTML rendered on the client right after the page loaded. It is very important that these two renders are identical, or lots of bindings bugs and other hard to track down problems could occur, since the ids could be out of sync.

This error can be a symptom of various bugs in Racer, and in this case there was an issue with subscribe callbacks returning too early in certain cases (why you were getting undefined results). Since the data rendered on the server right after the callback and the client had all the data available by the time that it rendered, there was some discrepancy.

I think we've fixed this issue as of 0.5.9, and I can't repro after generating a new default project with 0.5.9, so closing.

[hughlomas]

Having this issue on a freshly generated, unedited project. Derby -V reports as 0.5.9. Node is 0.10.13. Windows 7 x64.

[tssajo]

I still get the same error on a fully updated Windows 7 x64 system derby is 0.5.9 node is 0.10.12 (just updated to 0.10.13 -- it did not change anything regarding this issue)

According to this https://gist.github.com/lefnire/5959027 shouldn't the function createUserId inside /lib/server/index.js be written like this:

function createUserId(req, res, next) { var model = req.getModel(); var userId = req.session.userId || (req.session.userId = model.id()); model.set('_session.userId', userId, function() { next(); }); }

instead of the default:

function createUserId(req, res, next) { var model = req.getModel(); var userId = req.session.userId || (req.session.userId = model.id()); model.set('_session.userId', userId); next(); }

???

[hughlomas]

Ok, I just logged the HTML on the server and the client, the outputs can be seen here https://gist.github.com/hughlomas/6063488

However the only difference is that on the client the

<ui:connectionalert>

is rendered on the server as

<!--$components.$0--><div id=$1 class=ui-connection> 

Which is causing the mismatch in renderHash

[nateps]

Thanks for posting the HTML from the server and client; that is super useful. This is actually a major issue in this case, because as you can see, all of the ids are then offset after the initial render. For derby to function correctly in production, these ids must align, since the server and client mismatch is not detected, and this will lead to all sorts of bindings being broken.

It appears that for some reason the <ui:connectionalert> component is not being properly setup on the client, which may have to do with a bug loading the file in windows. Odd that it would still work on the server.

[digilord]

I am seeing this same error on a new project in Ubuntu. After a couple of edits to the HTML in /views/app/index.html the page gets out of sync. Manually reloading doesn't help. The only thing that seems to correct the issue is a restart of the server.

I can reliably get this to occur after trying to visit a link that there isn't a route for.

Update: I get this error EVERY manual reload.

[hughlomas]

Shouldn't this be an open issue?

[rnikitin]

I have same issue with freshly installed derby and default app.

[chuckpearce]

Just updated to Node v0.10.20

Used a git pull of both Derby and Racer, issue still persists on bleeding edge.

I am not sure about the rest of the Derby users but this is a major issue for us as it breaks the continuity between client and server and one of the primary reasons for using Derby.

[tssajo]

I agree, I'm not using Derby at all at the moment because of this issue.

[chuckpearce]

Glad I am not the only one, hopefully we can get this reopened. Willing to put in resources to track it down. I also tried running the 0.6 branch but ran into an issue node-saddle not having a .Template() function and .6 not having a View.server file in the repo.

So far been pretty happy with derby but this is a big problem for us in order to deploy anything with derby.

Are you currently using anything else for the server/client model propagation?

[tssajo]

There is Meteorjs which is similar to Derby but I don't like that it does not pre-render the pages on the server-side. If you do a View Source in the browser, you'll just see an empty page with a bunch of .js file includes. That's not good for SEO. Derby would be so much better in this area, I'd love to use Derby if it would not have this total showstopper bug. ;)

[chuckpearce]

Sounds like you went through a similar vetting process as us. I wasn't a fan of MeteorJS for other reasons as well. I will give it until the end of the day then I will likely open a new issue request referencing this one, can not believe this has been active for 3 months. Guess it may be our fault for updating a closed ticket :x I emailed Nate yesterday asking him to reopen this issue so hopefully he will have an opportunity to do so.

[tssajo]

Great! I'll be able to test proposed patches to fix this bug over this weekend on Win7 and CentOS 6 platforms. If anyone can come up with a proposed patch... ;)

[chuckpearce]

Any of you having this issue, check out ticket #346 for a fix. User cjblomqvist's has resolved this.

[mike-marcacci]

Has any progress been made here? I cannot use the workaround in #346 because I need access to the params variable in a route...

[icaliman]

I see removing < ui:connectionAlert> from views of newly generated project eliminates the issue.