[Improvement] Improve error messages context in Slack component

[Joycelyn-Chen]

Is There an Existing Issue for This?

• I have searched the existing issues

Are you willing to own the issue?

• I can own this issue

Where are you aiming to make improvements?

Instill Cloud

Is your Proposal Related to a Problem?

As mentioned in the discord #office-hour-chat, Slack SDK didn't contain much information about the cause of the error, making the debugging process when developing the Slack component extremely challenging.

Describe Your Proposed Improvement

As suggested by @jvallesm, we might be able to retrieve some key information by constructing a custom HTTP client and render the cause of the error from there.

Highlight the Benefits

So that everyone could enjoy developing the slack component better!

Anything Else?

I'm very interested in contributing to the custom HTTP client construction, I'm just wondering if this is still a valid direction to work towards?

[linear]

INS-6703 [Improvement] Improve error messages context in Slack component

[jvallesm]

Hi @Joycelyn-Chen thanks for opening this ticket! It seems a good issue, let me complete a bit your information with what I had in mind. Let's take the conversations list endpoint, for example.

• When calling the API, the Slack SDK parses the response into a struct that is composed with SlackResponse. The error is read from there a few lines below.
• If we follow postMethod, we see that the Client's httpclient is passed all the way down to the doPost.
• The challenge here would be passing the HTTP client option with an extension of *http.Client that intercepts the response on the Do method and, if contains an error body, creates an error that both can be handled by the Slack SDK and contains information about the request that failed (e.g. the URL). - The problem here is that it isn't Do's error what's bubbled up, but some processing by the SDK based on the body (successfully requested but with a non-OK status). You'd need to investigate how to make this work both with the SDK and with the component.
• For the user-facing error (once the error is captured at the component level), you can use errmsg. These errors are handled at the pipeline-backend middleware to format the error response.

💭 If this approach didn't work, the OptionDebug might be worth checking. Although it's not for production code, it can help devs understand what the SDK is doing.