Add default behaviors for non-200 responses

[StacieClark-Elastic]

Context:
We've been seeing support cases around error codes that integrations were not scripted to handle. Rather than adding loads of boiler plate code to existing and new integrations, we propose to create a handler or wrapper to a handler that can take options for how the handler responds to error codes.

Requirements:
To be able to write a script where the code handles the success case and all other cases are handled under the covers with no configuration
To be able to configure the handler behavior and/or messaging for some errors (Like 429) while using default behavior for the rest.

Things to consider:
How could this be used to help with observability of integrations. For instance, if an integration can list expected errors and starts seeing UN-expected errors, this may raise a flag that expected errors would not.
4XX errors are common when a user is setting up their integrations, yet we find that those problems end up in customer service. How do we surface those issues without having to look at logs.

[efd6]

What this seems like it might look like is a switch, which CEL does not currently support. This could be implemented via a composition of the as macro and a new switch extension corresponding to the Go expression switch construct. This would exist in two forms, with and without the switch expression, expr, and including in both forms cases and a default (required in CEL to ensure that all expressions are evaluable):

switch(expr <k>, cases <map<k,dyn>>, default <dyn>) -> <dyn>
switch(cases <map<bool,dyn>>, default <dyn>) -> <dyn>

These would be used like, e.g.:

}).do_request().as(resp,
  switch(resp.StatusCode,
    {
      200: {
        "events": <some work with resp>,
      },
      429: {
        "events": [{"message": "retry"}]
      },
    },
    // default:    
    {
      "events": {
        "error": {
          "code": string(resp.StatusCode),
          "id": string(resp.Status),
          "message": "GET:"+(
            size(resp.Body) != 0 ?
              string(resp.Body)
            :
              string(resp.Status) + ' (' + string(resp.StatusCode) + ')'
          ),
        },
      },
    }
  )
)

or in the two-arg form

}).do_request().as(resp,
  switch(
    {
      resp.StatusCode == 200: {
        "events": <some work with resp>,
      },
      resp.StatusCode == 429: {
        "events": [{"message": "retry"}]
      },
    },
    // default:    
    {
      "events": {
        "error": {
          "code": string(resp.StatusCode),
          "id": string(resp.Status),
          "message": "GET:"+(
            size(resp.Body) != 0 ?
              string(resp.Body)
            :
              string(resp.Status) + ' (' + string(resp.StatusCode) + ')'
          ),
        },
      },
    }
  )
)

It's important to note that objects in CEL can be keyed on the same types as in Go, so we can use the second, two-arg, form, and we can make our cases be any CEL type based on a Go comparable type.

There is an issue with this design that I think is a blocker; the cases map would need to be evaluated before calling the switch, resulting in potentially significant fruitless work. To deal with this, we would need to make it a macro with arbitrarily many arguments, but this is not supported by the language, so we devolve to trying to implement cases as a sequence of if..elseif..else, which we can already do with the ternary operator.

[efd6]

Having thought about this for the past couple of days, I'm leaning more and more towards WONTFIX.

[StacieClark-Elastic]

What about a request type that handles every non-200 results in a specific way that does not need to be coded? My goal here is to

1. reduce boiler plate code that some developers may not even add.
2. Have a canonical way of handling errors that is understood by all who use that request.

I suspect that the structure of CEL cannot support that easily.

We have had issues where APIs return a different code for 429. That was one of the issues.

[efd6]

I suspect that the structure of CEL cannot support that easily.

Yes, this is the issue, though "structure" is heavily load-bearing here. The approach that I have above would be fine, but for the fact that all branches must be evaluated before the switch call. We can do that, but it's horrifically inefficient. This is the basis for the WONTFIX.