Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stored procedures swallow errors emitted from async function calls #46

Open
Oblarg opened this issue Apr 27, 2020 · 0 comments
Open

Stored procedures swallow errors emitted from async function calls #46

Oblarg opened this issue Apr 27, 2020 · 0 comments

Comments

@Oblarg
Copy link

Oblarg commented Apr 27, 2020

Describe the bug
If a stored procedure calls an async function, and that function throws an error, the client response will still have status code 200, and the error will not be present anywhere in the response body (the resource of the response will be set to an empty string). This is the case even if catch() is called on the promise.

To Reproduce
Steps to reproduce the behavior:

  1. Create the following stored proc:
() => {
  (async () => {
    throw new Error('foo');
    getContext().getResponse().setBody('hello world');
  })();
}
  1. Execute the stored procedure through your API of choice.

Appending an error handler that places the error in the response body works as expected, but this is a lousy workaround as the HTTP status code of the response will still be OK.

Note that this does not occur if an error is thrown directly from an ordinary function; it only occurs if an error is thrown from an async function (even if, as above, the function never suspends execution).

Expected behavior
The error should be correctly propagated to the response body and the corresponding HTTP status code should indicate an error state. This could either be built in to the runtime, or else exposed as a handler that can be passed to a promise's catch block.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant