Open selkovjr opened 10 years ago
Thanks for pointing this out. The OutputBuffer's undefined id is definitely something we should fix; there are a couple of places where error messages can be more clear. I am not sure what is going on exactly, but I will try to setup a test case where there is a tunnel call that ends up calling ac.error. Mojito should be able to handle passing an object to ac.error. The best way to debug what is going on is to go through the call stack within ac.error and see where the response is getting malformed resulting it what seems to be a JSON parse error.
I have a mojit with a binder that tunnels a database query to its server-side controller. In the binder, the response is processed by a ModelList hooked to a DataTable. Everything works fine as long as there are no errors in the database. In the case of an error, everything works up to the point when the controller calls
ac.error(err)
, whereerr
has the following form (as I get it frompg
and as rendered byconsole.log
in the server):I haven't tracked all the goings-on between the call to
ac.error()
and the moment when stuff gets written to the socket, but at the other end of it, I seewhile
mojito-output-buffer
reports:This raises a few questions:
id
in OutputBuffer? What does it mean and how do I define it?error
event not fire immediately? Instead, it fires like this half-a-minute later:I will appreciate any clues for how to debug it further, or for how to do it right.