[Bug]: configmaps -- convert errors to e.response.data.message

[andrewballantyne]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

#281 is kinda our catchall to improving errors. More specifically we show errors in the logs that are just noise and will make it hard to see real issues.

Downstream issue: https://issues.redhat.com/browse/RHODS-5079

Expected Behavior

Not to show errors of 404 nature in the logs unless they are important fail points. Not getting back a configmap, secret or pvc is just that they are not there. If that's logically a bad thing, the frontend should present that to the user... but we shouldn't log it on the backend.

Three suspected changes:

1. Avoid fastify.log when 404 in non critical usecases
2. Still send the error back to the frontend so it can handle it
3. Make the error message show the actual error message by digging into the e.response object -- .data.message is probably what you want

Also could we move the error handling to a .catch on the fastify.kube call that way we only need to deal with objects from the kube library and not a runtime issue with JS.

Steps To Reproduce

New user spawning a Notebook will get a 404 on configmaps and secrets. These appear in the logs and they should not.

Workaround (if any)

No response

OpenShift Infrastructure Version

No response

Openshift Version

No response

What browsers are you seeing the problem on?

No response

Open Data Hub Version

2.1

Relevant log output

No response

[andrewballantyne]

Secrets and PVCs were caught in other issues -- just configmaps left.