[usability] Template/demo CloudEvents functions replies with non CloudEvents

[slinkydeveloper]

Does the issue result in incorrect behavior?
Both in node and quarkus event function templates, the response is a non cloudevent. This behaviour is not "eventing-friendly" and we should discourage it. The reply to a trigger invocation can be only a cloudevent, otherwise the response is discarded (which is what happens in that case https://github.com/knative/eventing/blob/master/pkg/mtbroker/filter/filter_handler.go#L281)

Suggest an alternative
All CE templates should reply with cloudevents or nothing

[matejvasek]

@slinkydeveloper Do you mean than in language object is not CE, or that resulting HTTP is not CE?

[matejvasek]

I tried cURL the echo() function and I got CE back.

[slinkydeveloper]

Ok i'm sorry i didn't specified the runtime, this happens with node:

function processCustomer(customer, context) {
  console.log(customer, context)
  if (!context.cloudevent) {
    return 'No cloud event received';
  }
  context.log.info('Processing customer', customer);
  context.log.info(`CloudEvent received: ${context.cloudevent.toString()}`);
  return { customer };
};

This returns a non cloudevent as response:

% curl -X POST -v -d '{"hello": "world"}' \ 
    -H'Content-type: application/json' \
    -H'Ce-id: 1' \
    -H'Ce-source: cloud-event-example' \
    -H'Ce-type: dev.knative.example' \
    -H'Ce-specversion: 1.0' \
    http://localhost:8080

Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying ::1:8080...
* connect to ::1 port 8080 failed: Connessione rifiutata
*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.69.1
> Accept: */*
> Content-type: application/json
> Ce-id: 1
> Ce-source: cloud-event-example
> Ce-type: dev.knative.example
> Ce-specversion: 1.0
> Content-Length: 18
> 
* upload completely sent off: 18 out of 18 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< content-type: application/json; charset=utf8
< access-control-allow-methods: OPTIONS, GET, DELETE, POST, PUT, HEAD, PATCH
< access-control-allow-origin: *
< content-length: 30
< Date: Thu, 29 Oct 2020 16:15:57 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host localhost left intact
{"customer":{"hello":"world"}}%      

In Quarkus, the signature doesn't return a cloudevent but Object, but some "hidden magic" happens behind the hood and wraps my value into a cloudevent. It works but it's not explicit, defaulting some values to method name etc... That sounds weird, I would prefer an example that explicitly show how i can create a new cloudevent to return

% curl -X POST -v -d '{"hello": "world"}' \
    -H'Content-type: application/json' \
    -H'Ce-id: 1' \
    -H'Ce-source: cloud-event-example' \
    -H'Ce-type: dev.knative.example' \
    -H'Ce-specversion: 1.0' \
    http://localhost:8080

Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying ::1:8080...
* Connected to localhost (::1) port 8080 (#0)
> POST / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.69.1
> Accept: */*
> Content-type: application/json
> Ce-id: 1
> Ce-source: cloud-event-example
> Ce-type: dev.knative.example
> Ce-specversion: 1.0
> Content-Length: 18
> 
* upload completely sent off: 18 out of 18 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< ce-id: 1ed57840-3b7a-4f0f-93b4-0e34edda50c8
< ce-specversion: 1.0
< ce-source: echo
< ce-type: echo.output
< Content-Type: application/json
< content-length: 17
< 
* Connection #0 to host localhost left intact
{"hello":"world"}%  

[lance]

The fix for this involves both faas-js-runtime (see nodeshift/faas-js-runtime#68), and the templates in faas. Transferring to boson-project/faas to track the template changes needed.