Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

bshaffer
Copy link
Collaborator

@bshaffer bshaffer commented Nov 6, 2020

See #60

The invoker catches all throwables of type Exception (note: Error types are not handled).
The invoker then sets:

  • the response status code to 200
  • the X-Google-Status response header to "error" (cloudevent) or "crash" (http)
  • the response body to the error message

The invoker logs an error to stderr with a json-formatted stack trace.

Other notes:

  • The end user cannot set status codes for Cloud Events
  • Invalid responses from http functions now result in a LogicException

@bshaffer bshaffer requested a review from grayside November 6, 2020 15:35
@bshaffer bshaffer requested a review from mtraver November 6, 2020 15:39
Comment on lines +46 to +48
throw new \LogicException(
'Function response must be string or ' . ResponseInterface::class
);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the increased certainty this provides. Good idea!

'Invalid signature type: "%s"', $signatureType));
}
$this->errorLogFunc = function (string $error) {
fwrite(fopen('php://stderr', 'wb'), json_encode([
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this error also get routed to Error Reporting on Cloud Functions? (Sending further context in chat.)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope so!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to manually test. If it doesn't work, we might not want to make the change.

src/Invoker.php Outdated
: 'error';
return new Response(200, [
FunctionWrapper::FUNCTION_STATUS_HEADER => $statusHeader,
], $e->getMessage());
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error message might surface implementation details of the function, maybe it should respect display_errors?

Copy link
Collaborator Author

@bshaffer bshaffer Nov 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I am also okay omitting it to be safe. I was following Node's implementation.

Copy link
Collaborator Author

@bshaffer bshaffer Nov 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed the error from the response for simplicity for now

Copy link

@grayside grayside left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM except I think we need to clarify the Error Reporting compatibility.

Copy link

@grayside grayside left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per further discussion, the error reporting consideration doesn't seem like a blocker.

@bshaffer bshaffer merged commit 86cdead into master Nov 6, 2020
@bshaffer bshaffer deleted the error-handling branch November 6, 2020 21:00
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

Successfully merging this pull request may close these issues.

2 participants