Handle Thrown Exceptions

[grayside]

Current Behavior

If an exception is thrown in developer code, the functions framework leaves it unhandled.

functions-framework-php/src/CloudEventFunctionWrapper.php

Lines 62 to 63 in dba0a47

	call_user_func($this->function, $cloudevent);
	return new Response();

Assuming nowhere else in the Function Framework catches the exception, this will ultimately crash the FPM process. FPM error logging will probably handle that crash (and place in Error Logging), but the next request will incur cold start costs.

In addition to the crashing, this means developers do not have a mechanism to request a Pub/Sub retry without triggering a crash.

Expected Behavior

• Functions Framework catches the thrown exception, creates an HTTP 500 response, and logs the error.
• Exceptions do not crash the FPM process. If the developer wants to stop the container use exit().
• Logged error should align with the format for error grouping and lift to Cloud Error Reporting if possible
• X-Google-Status header is set to error. I'm not familiar with what this does, but see it in multiple frameworks. Maybe @grant has insight?

Other Language Implementations

Golang Implementation

Node.js can infer errors from callbacks and rejected promises in addition to thrown errors. On any error, set X-Google-Status header to 'error':

https://github.com/GoogleCloudPlatform/functions-framework-go/blob/fed357741a8521eeeaad9b32dc140d69ea69626c/funcframework/framework.go#L207

On thrown errors, send a crash response:

https://github.com/GoogleCloudPlatform/functions-framework-nodejs/blob/01b7df3128cd5c6b736aa0c6cedb35e53a3e92ad/src/invoker.ts#L247-283

https://github.com/GoogleCloudPlatform/functions-framework-nodejs/blob/01b7df3128cd5c6b736aa0c6cedb35e53a3e92ad/src/logger.ts#L25-52

Node.js Implementation

Set X-Google-Status header to 'error' and return the error message:

https://github.com/GoogleCloudPlatform/functions-framework-nodejs/blob/01b7df3128cd5c6b736aa0c6cedb35e53a3e92ad/src/invoker.ts#L65-72

[bshaffer]

Looking at NodeJS, it seems that "error" and "crash" handle very similarly. The "error" status is used for events, and the "crash" status for HTTP. In both case, the following happens:

• Functions framework sets "X-Google-Status" response header to "crash" or "error"
• Functions framework sets the error message as response body
• Functions framework uses console.error to log the error / stack trace
• Functions framework does not set a status code.

My biggest questions are:

• In my testing, the status code remained 200, even when an exception is thrown. Is this the expected behavior?
• Can event responses (status code / body) be set by the cloud event function?
• Is X-Google-Status always "crash" for http and "error" for cloud events?

[mtraver]

Looking at the Go FF, I see non-200 status codes returned along with "crash" and "error" headers:

• https://github.com/GoogleCloudPlatform/functions-framework-go/blob/fed357741a8521eeeaad9b32dc140d69ea69626c/funcframework/framework.go#L51
• https://github.com/GoogleCloudPlatform/functions-framework-go/blob/fed357741a8521eeeaad9b32dc140d69ea69626c/funcframework/framework.go#L160
• https://github.com/GoogleCloudPlatform/functions-framework-go/blob/fed357741a8521eeeaad9b32dc140d69ea69626c/funcframework/framework.go#L166
• https://github.com/GoogleCloudPlatform/functions-framework-go/blob/fed357741a8521eeeaad9b32dc140d69ea69626c/funcframework/framework.go#L198
• https://github.com/GoogleCloudPlatform/functions-framework-go/blob/fed357741a8521eeeaad9b32dc140d69ea69626c/funcframework/framework.go#L207

The Go FF does use the "error" header only in event functions but "crash" is used in event functions too: https://github.com/GoogleCloudPlatform/functions-framework-go/blob/fed357741a8521eeeaad9b32dc140d69ea69626c/funcframework/framework.go#L198

Looks like "crash" is used for bad event data, and "error" is used for an error in function execution.

[bshaffer]

@mtraver thank you for this! I couldn't parse the Go code as well as I'd like.

I've updated to return 400 Bad Request when the request body is invalid (and "crash" for the status header), and 500 Internal Server Error any other time an exception is thrown.

Go uses 415 Unsupported Media Type when the body can't be read, but I'm not really sure what the analog is for PHP so I left that out.

[grayside]

HTTP 415 seems appropriate per https://tools.ietf.org/html/rfc7231#section-6.5.13

[grayside]

While progress was made, this issue is still open because there are further aspects of error handling not defined in the Functions Framework Spec, but PHP has differences with other languages.