Errors

I try to make the errors as easy to understand as possible, but sometimes they might be a bit complex or misleading for one reason or another.

Request errors

• System.InvalidOperationException: No mapping exists from object type Dapper.SqlMapper+DapperRow
  • This means one of your @params values is incorrect, perhaps you didn't go deep enough into an object. For instance, this was reported when a user had a query like createUserId in @user rather than createUserId in @user.id

Websocket errors

The websocket endpoint api/live/ws handles critical and non-critical errors slightly differently, but will ALWAYS be sent in the familiar websocket response (the json object with the error field). Errors are considered critical if the websocket can no longer be serviced and thus will close immediately after sending the error response. Errors are non-critical if you made some kind of bad request, something which doesn't impact the state of the websocket.

Critical errors are indicated by a unique response type, which currently consists of:

• badtoken
• unexpected

More may be added in the future. For now, if you EVER receive these types, whether from a request or just arbitrarily (live updates can throw them), you should consider the websocket unsalvageable, and you'll want to create another, perhaps with all data reset.

Non-critical errors keep the response type you'd normally receive from that request, which usually matches the request type. In this case, just the error field will be set, indicating that your request could not be processed due to an error. This is true of critical errors as well: the error field will ALWAYS and ONLY be set for actual errors, so your error handler can simply always check for that field.

This split between critical errors getting their own type and non-critical just being returned like a normal response is to help facilitate websocket code. In your message loop, you can simply check type to know at a glance where to send the response or how to handle it. Chances are high that the function making a request will want to handle the non-critical error, and not be handled arbitrarily by the websocket. However, this system still lets you do so, as you can check the "error" field if you want arbitrary error handling.

I also recommend using a unique id for each request in the id field, so that you can always match your responses to your requests. I use Math.rand() in my own code.

Critical error caveat

You'll notice that there is currently no critical error type reserved for bad lastId. They are returned as unexpected, which lumps them together with other unexpected error types. I do eventually want to make that error type unique so you can more easily attempt to salvage the connection without reloading the page, but it's low on my list of priorities. What this means is: if you reconnect after a server restart and your lastId is too high, or you haven't reconnected in a long time and you give a lastId that is too low, you will receive an unexpected critical error, same as if the websocket died for other unexpected, truly unsalvageable reasons.