Change Slack unmarshalling error from error to warning level #619
Comments
|
Hi @bygui86, thanks for reporting that. FYI: it duplicates #579 And it was addressed already in #610 and sensitive data is not printed to logs (see: slack-go/slack#1067). AFAIK with the current library we are not able to ignore certain events. We get all of them, right @pkosiec?
Unfortunately, it's a generic |
|
I agree, this is something related to how the library works. What we can think about is changing the log level from error to But as you wrote @mszostok, the issue with printing sensitive data is already resolved. |
|
So I added this issue for v0.13.0 to change the level from |
mszostok
changed the title
mszostok
added
slack
and removed
duplicate
|
@mszostok thanks for your answer and sorry for the possible duplication, I missed that issue. But actually my point is a bit different... # ...
case *slack.UnmarshallingErrorEvent:
if ! strings.Contains(ev.Error(), "user_status_changed") {
b.log.Errorf("Slack unmarshalling error: %+v", ev.Error())
}
# ...It would be a nice improvements, since I see such log line really often! |
@mszostok sorry but changing the log level won't solve anything... in the logs I will see anyway such line... |
I understand, however, you can change the log level with The solution you mentioned is OK as a workaround, but it's too error-prone to maintain that. It's not a good practice to assert the error message, as it's meant for humans. We cannot expect how this will work in the future release of The best option is to subscribe to required events only. The other option is to cast the
Personally, I will vote for checking whether there is an option to subscribe to required events only. If not possible, check if we can contribute such support to slack-go lib (only if it's not too complicated and won't take too long). Otherwise, I would leave it as it is and log it as warning. |
That's something beyond Anyway, I also think it will be the best to keep this event logged, but with different level 👍 |
@mszostok yeah you are right, it would be way better to subscribe to required events only.
@pkosiec thanks for suggestion, I check asap! |
|
@pkosiec sorry I thought you were referring to a specific configuration of BotKube app installation in our Slack workspace, but I don't find anything. Are you talking about BotKube app implementation itself? |
|
Sorry @bygui86, somehow I missed your message. What I meant is the BotKube Slack app from the Slack App directory: https://slack.com/apps/AF5DZLHPC-botkube?tab=more_info So, unfortunately it is not about a specific Slack app installation (which you do by "Add to Slack" button), but rather the global configuration. We'll need to look into that if we can narrow it down, but in the meantime we will change the level of these log messages. Stay tuned for updates! |
|
@pkosiec thanks for the clarification! |
##### SUMMARY
This PR only decreases the unmarshall error severity from err to warn. To make it a bit better, we can contribute to the `slack` lib and replace:
```go
err := fmt.Errorf("RTM Error: Received unmapped event %q", typeStr)
```
_([source](https://github.com/slack-go/slack/blob/1dcd0d459a30d8402f5c0c42e20df80b56dac5e3/websocket_managed_conn.go#L477))_
with error type `UnmappedError`. This won't be a breaking change for them, so we should be able to merge that.
As a result, we will know the details about the error and could implement sth like:
```go
// handlingEvents holds event names which have corresponding handling logic.
var handlingEvents = sets.NewString("message", "connected")
// trimmed
case *slack.UnmarshallingErrorEvent:
err, ok := ev.ErrorObj.(slack.UnmappedError)
if ok && !handlingEvents.Has(err.EventType()) { // it's not an err for us, as we don't care about this event type.
b.log.Debugf("Slack unmarshalling error: %+v", ev.Error())
continue
}
b.log.Errorf("Slack unmarshalling error: %+v", ev.Error())
```
In that way even if someone will configure custom Slack bot with wrong event subscription we will be able to “ignore them”.
WDYT? Is it worth it? If we stay with RTM, then it's the only option.
##### FINDINGS
I wanted to describe the workaround for this issue by creating the own Bot. I found that the current Bot is based on RTM. This means that it issues the [old API](https://api.slack.com/rtm).
In this case, we are not able to:
- reduce the app permission
- select events to which we want to be subscribed
The best option would be changing the implementation from RTM to [WebSocket mode](https://api.slack.com/apis/connections/socket). Should I create an issue?
Related issue:
- #619
|
After doing my investigation I realized that it won't be as easy as described, first we need to do the migration, please see and follow dedicated issue for that: #631 The alternative workaround was described in the PR #629, so I will create a dedicated PR against slack lib and see whether they will accept it or not (slack-go/slack#1086). |
Describe the bug
I configured BotKube to send messages over Slack. BotKube app is installed in Slack workspace, I receive messages in different channels, everything work fine. But in the BotKube logs I see tons of "Slack unmarshalling error: RTM Error: Received unmapped event "user_status_changed"" messages like this
BotKube configuration
To Reproduce
Steps to reproduce the behavior:
Expected behavior
BotKube should ignore such messages without logging as error or directly not receiving such messages.
Additional context
K8s provider: GCP/GKE
K8s version: v1.21.11-gke.900
BotKube version: v0.12.4
The text was updated successfully, but these errors were encountered: