Right now we're treating all JS errors in server of sandbox as 500 server error. So the sandbox keeps running and the error is ignored by the host (because it assumes it's an app error). But some errors are clearly indicative of a problem with host. Consider this from routeserver.ts:
const matched_route = headers.get("X-Dropserver-Route-ID");
if( matched_route === null ) {
this.replyError(reqEvent, "X-Dropserver-Route-ID header is null");
// How would this happen? No sure, but it's not an app error,
// it's DS that didn't registerroutes correctly, or some other snafu.
return;
}
Most errors there are like that.
In addition we should define an error type in dropserver_lib_support that indicates an error in the dropserver_app lib that is not due to app code. This will help catch incompatibilities between lib code and sandbox code.
Context: I tried running an app that is ds_libe_support 0.1.1 on DS v0.8 which is on 0.2. Result is 500 errors, but nothing to indicate to host that app is malfunctioning.
Right now we're treating all JS errors in server of sandbox as 500 server error. So the sandbox keeps running and the error is ignored by the host (because it assumes it's an app error). But some errors are clearly indicative of a problem with host. Consider this from routeserver.ts:
Most errors there are like that.
In addition we should define an error type in dropserver_lib_support that indicates an error in the dropserver_app lib that is not due to app code. This will help catch incompatibilities between lib code and sandbox code.
Context: I tried running an app that is ds_libe_support 0.1.1 on DS v0.8 which is on 0.2. Result is 500 errors, but nothing to indicate to host that app is malfunctioning.