Question: how to improve troubleshooting

[adrukh]

The JSON schema of the incoming webhook request payload is quite elaborate, and obscure at the same time. The Microsoft Teams API isn't making it too easy to troubleshoot deviations. An example is a response body of Bad payload received by generic incoming webhook. with an HTTP status code of 400... You get the point.

While there's little we can do to help Microsoft document its APIs better, the current implementation of the HTTP client request masks the few details the API returns in cases of failure. Specifically, the Error object thrown by axios in case of an HTTP 400 has .response.data as the response payload, but the .response object isn't serializable, and doesn't get logged properly.

I'd like to address this and make this library more helpful in troubleshooting scenarios. My question is what would be the preferred way to do so:

1. Replace the HTTP client being used to something that surfaces the response payload in case of an error. I personally like got, but open to other suggestions. I think got does a better job with error handling, need to validate this.
2. Handle the error thrown by axios as part of this library, and introduce some logic that glues Microsoft's API to user needs in a better way.
3. Some other option I didn't consider yet?

[waigel]

First, thank you for your interest in this project.

I know Microsoft is very thrifty with individual bugs, which makes it difficult at times. So I am very open to your ideas.

Personally, I don't know the lib "got". But if you are convinced that the error handling will be better, feel free to try it. Otherwise, we could catch the axios exceptions and throw our own user-friendly errors. If you need help with the implementation, get in touch with me anytime.

[adrukh]

Thanks @VerHext for the speedy response. I'll open a draft PR to pin the response body onto the error object, sticking to the current implementation. Let me know what you think.

[adrukh]

Please see #5