Include traceback into error response when function raises exception

[denismakogon]

As IronFunctions user, i want to receive function traceback on error as part of HTTP response to function execution.

If function raises exception API return nothing except HTTP code - 500 with no response body, see this link.

As one of solutions mentioned by @pedronasser would be to include stderr content into response with making such capablity configurable through API (by default - disabled capability).

In case if function exited with traceback - make error message more verbose.

[treeder]

Regarding response bodies, agree, we should try to make every response a JSON response, with appropriate information in the json error message, as we do with other errors.

That said, it really depends on the error as to what we return to the user. The user shouldn't know about a backend database error or something. Some things should just be logged and return an internal server error to the user. Similar to a website, where it says to try again later. Errors like 4XX errors should return helpful messages, but 5XX errors may not be appropriate to return to the user.

[pedronasser]

@treeder But there must be some situation/case that the developer want to get the error (even internal) inside the function response body, or not?
Not all functions will be done for public users, may exists functions for internal uses as well.

[ucirello]

It seems that is slightly more complicated than what's being talked here.

In this particular switch block, an 500 error is a sort of catch-all handler. And the driver itself, has more states than the ones handled. Check https://github.com/iron-io/runner/blob/master/drivers/driver.go#L67

I am not sure that an output will always be available in case of execution failure - and keep in mind that this error is at container-driver level; not application level. It means that the application should be able to detect its own errored state and print it somehow either to stdout or stderr - which in this case will be a 200 with a proper response body.

[pedronasser]

@ccirello Agreed. But the issue here is not how the runner handle the container status (surely that need to be improved).

This issue is about letting the user (some how) configure if the container will output the container stderr inside the response body.

I've suggested exactly that: the container could handle any exception (like database) and send that to the stderr in order to send it to the functions logs. But that doesn't solve the problem of the user receiving any container logs in the response body.