HTTP Response StatusCodes from EventListener #931
Labels
kind/api-change
Categorizes issue or PR as related to adding, removing, or otherwise changing an API
kind/feature
Categorizes issue or PR as related to a new feature.
Milestone
Background
Today the EventListener waits for at least one resource to be created before returning a HTTP response. We return 201 if a resource is created and 202 otherwise. If we fail to create a resource due to an auth error, we return a 401 response instead.
Note that the 201 status code, the user still may not know exactly what resource was created. They'd still have to look into the EL logs (using the eventID from the HTTP response) to find out which resource was created.
Problem
If an EL is handling many triggers (or a single trigger had many interceptor calls), the EL will take a long time to respond and may even time out. The webhook originator (e.g. GitHub) don't generally care about the response codes (unless its 5xx)
The 201 status code gives the impression that everything succeeded while that may not be the case always e.g. one trigger might succeed while another failed (see EventListener return a 2xx status on failure #656, Add Error Msg and BadRequest for Parsing error #758)
Proposal
I'd propose we return a response back as soon as the EL has read the body. We'd return a 2xx if we can fully read the body as a valid JSON document, and 4xx otherwise. We'd still return an eventID (and the name and namespace of the EventListener) so that the user can track the progress of the trigger.
The text was updated successfully, but these errors were encountered: