Closed cooperneil closed 3 years ago
There's nothing in the FF cloudevents
signature preventing a return value/error return.
The developer's function must either explicitly or implicitly signal that it has completed performing useful work. The function may explicitly signal this condition by explicitly returning. The function may implicitly signal this condition by simply evaluating until it reaches the end of the function's code block.
The sample interface change seems like a request for the Go Functions Framework. Is that right?
Yep, minimally its a request for the Go Framework, and also the starting point of the discussion of whether the FF contract should more explicitly indicate that each language SDK should allow the the function developer to "return an error in a language-idiomatic manner"
I don't see how the signature disallows this. Can you make a PR with more concrete details?
We do allow errors in responses, stated here:
https://github.com/GoogleCloudPlatform/functions-framework#http-status-codes
Closing due to inactivity.
The CloudEvent signatures should allow for an error return. This can signal the sender that there has been a delivery failure, at which point the sender can determine whether to retry event delivery.
For example, here are some relevant areas of the Knative spec: http support, errors
This implies that, for example, the golang CloudEvent Receiver signature should support the form:
func myFunction(ctx context.Context, event cloudevents.Event) error
and not just:
func myFunction(ctx context.Context, event cloudevents.Event)
(Note that it could be possible that a Functions Framework SDK support both forms, but minimally the requirement would be to allow the function developer to return an error in a language-idiomatic way)