Closed Parama92 closed 1 month ago
Thanks for the contribution! Before we can merge this, we need @Parama92 to sign the Salesforce Inc. Contributor License Agreement.
Thanks for the feedback! I have addressed the comments and have re-requested a review
I have addressed the issues that caused the linter to fail. It is running fine on my local machine now. Do you mind running the workflow once again?
Hmm, seems like the tests are still failing. It looks to me like something is blocking the testing process; see the CI output here. I can also reproduce this behaviour locally on my macbook pro using node v20.
I believe what is happening is that, because in the tests we return an error / a non-200 HTTP response, web-api
will by default attempt to retry issuing the request (see this default option). The default retry mechanism is "10 retries in 30 minutes" - meaning, if the Slack API returns an error result (like the "fake" API behaviour in the new tests you added), web-api
will block the process in order to retry the request, blocking the process for up to 30 mins! I believe this is what is causing the tests to hang.
As per our documentation on retries, try setting this option in the tests on WebClient to turn off retries:
{
retryConfig: { retries: 0 },
}
It's also a good idea to run npm test
locally before pushing any changes to make sure everything works as expected on your machine.
Hmm, makes sense. Strange that it seemed to work fine on my local system earlier.
Thanks for the heads-up though! I make the necessary changes and ran npm test
. I am getting an unrelated error, which didn't show up in any of the test runs here 🤔 -
Hopeful that this time it will work out fine! 🤞
Summary
In this PR, we aim to prevent the logging of message content when a request error occurs while attempting to invoke any of Slack's web APIs.
It solves this issue.
The problem at a glace -
The Error type -
WebAPIRequestError
, contains a property calledoriginal
which holds the raw error received fromaxios
. Theconfig
property within thisoriginal
is a part of the error data received fromaxios
. Thisconfig
property might in turn hold adata
property, which is the "message" we are trying to opt-out of showing.Tests conducted -
Error log with the opt-out config -
Note: The
original
property is missing from the Error object.Error log without adding the config -
Note: The
original
property is present in the Error object along with all the details of the request.Requirements