Fix s3 integration error handling

[deanhannigan]

Description

The default behaviour for handling integration errors is to throw the error and have koa relay it as a 400.
If an error object thrown by an integration contains a statusCode, koa will ignore the 400 and use that instead.

In development, if you encountered a permission restriction with your S3 integration, the AWS client would return a 403 and log you out. In prod, the page you were on would reload and you would lose the error message.

All errors in the S3 integration throw a new instance of Error with any relevant messaging. This will then be relayed with the default 400 status.

Addresses

• When creating and testing query in the S3 connector the builder crashes/reloads #14935

Launchcontrol

S3 integration error handling updated

[qa-wolf]

QA Wolf here! As you write new code it's important that your test coverage is keeping up.
Click here to request test coverage for this PR!

[aptkingston]

LGTM but will let someone from firestorm review too.

[samwho]

Could you add { cause: e } to this to make sure we don't lose the stack trace? I think you'd need to do something like this:

try {
  // ...
} catch (e: unknown) {
  if (e instanceof Error) {
    throw new Error(e.message, { cause: e })
  }
  throw new Error("AWS S3: Unable to process request")
}

Alternately, is it enough to target the problem Koa behaviour directly like this:

try {
  // ...
} catch (e: unknown) {
  if ("statusCode" in e && e.statusCode === 403) {
    e.statusCode = 400
  }
  throw e
}

Alternately alternately should we even trust 403s from integrations at all? Is there ever a case where we want to log the user out if an integration returns a 403? Should we go right to the source and map an integration 403 to 400 in all cases in whatever relevant bit of Koa is handling that?