Remove full event details from UnmarshallingErrorEvent #1067
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced May 19, 2022
mergify bot
pushed a commit
to kubeshop/botkube
that referenced
this pull request
May 26, 2022
##### ISSUE TYPE - Bug fix Pull Request ##### SUMMARY - Do not log full Slack event details in case of unmarshalling error This is an issue of the upstream library. While I prepared a workaround, I also prepared a simple change in `slack-go/slack` repo: slack-go/slack#1067 **NOTE:** This pull request depends on #582. Please merge #582 first, and I will rebase this one. Actual changes on this PR: 7813821 Fixes #579 ##### TESTING See the original issue for testing instruction: #579 You can use `pkosiec/botkube:slack-unmarshall-err` Docker image for testing the workaround. Once you run my image and try to reproduce the issue, you'll see in the logs: ``` ERRO[2022-05-19T16:00:57Z] Slack unmarshalling error: RTM Error: Received unmapped event "user_huddle_changed" ERRO[2022-05-19T16:00:57Z] Slack unmarshalling error: RTM Error: Received unmapped event "sh_room_join" ERRO[2022-05-19T16:01:00Z] Slack unmarshalling error: RTM Error: Received unmapped event "sh_room_leave" ```
kanata2
approved these changes
Jun 6, 2022
mergify bot
pushed a commit
to kubeshop/botkube
that referenced
this pull request
Jun 6, 2022
… details from logs #610 ##### ISSUE TYPE - Feature Pull Request - Bug fix Pull Request - Docs Pull Request ##### SUMMARY ~⚠️ **NOTE:** For convienence, this PR depends on #603 and needs to be rebased when #603 is merged (it should happen very soon). Actual changes: a6d91f21f25f00d679572e62b45cd2396d571075~ As the upstream fix has been merged (slack-go/slack#1067), this PR updates `slack-go/slack` dependency and removes no longer needed workaround. See the original issue: #579 See the PR that introduced the workaround: #583 ##### TESTING > **NOTE:** You can also use `pkosiec/botkube:rm-slack-workaround` Docker image for testing. The image was repushed **after** rebase. 1. Checkout this PR 2. Edit `comm_config.yaml` and enable Slack 3. Export needed envs: ```bash export KUBECONFIG=/Users/$USER/.kube/config export LOG_LEVEL=info ``` 4. Run BotKube locally: ```bash go run ./cmd/botkube/main.go ``` 5. Start Slack huddle and say something, then leave 6. Observe logs still without event details
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi 👋
When an unknown Slack event is received (e.g. unsupported Huddle-related events like
user_huddle_changedorsh_room_join), the library sendsUnmarshallingErrorEventcontaining full event details data, including some pieces of personal information about the user.This is a part of this error message when calling
err.Error()on suchslack.UnmarshallingErrorEvent:It is a problem, because such error should be presented to a user in some way. As this is a string, it needs some string manipulation to remove the event details. I think it shouldn't work that way.
While there are different options to solve this, I went with the simplest option: do not concatenate the event details to the error message 🙂 It brings consistency across all errors that are returned as incoming events. Also, there is still debug logging around UnmarshallingErrorEvents, so basically the change doesn't impact anything.
Let me know what you think 🙂 Cheers!