Unmarshal error on RTM, after updated to the new Slack version

[nazariinovak]

Hello,

We have a bot, that is set up something like

go s.rtm.ManageConnection()
...
for {
			select {
			case msg, ok := <-sh.rtm.IncomingEvents:
fmt.Printf("receivedMessage: %+v\n", msg)
                        ...
}

And when we're debugging in that fmt.Printf, we receive different messages if we ping the bot from older versions of slack on mobile vs the new slack on desktop

Old version (mobile) debugging:

receivedMessage: &{Msg:{Type:message Channel:<redacted> User:<redacted> Text:ping Timestamp:1573030654.004800 ThreadTimestamp: IsStarred:false PinnedTo:[] Attachments:[] Edited:<nil> LastRead: Subscribed:false UnreadCount:0 SubType: Hidden:false DeletedTimestamp: EventTimestamp:1573030654.004800 BotID: Username: Icons:<nil> Inviter: Topic: Purpose: Name: OldName: Members:[] ReplyCount:0 Replies:[] ParentUserId: Files:[] Upload:false Comment:<nil> ItemType: ReplyTo:0 Team:<redacted> Reactions:[] ResponseType: ReplaceOriginal:false DeleteOriginal:false Blocks:{BlockSet:[]}} SubMessage:<nil> PreviousMessage:<nil>}

New version (desktop) debugging:

receivedMessage: {Type:unmarshalling_error Data:RTM Error: Could not unmarshall event "message": {"client_msg_id":<redacted>,"suppress_notification":false,"type":"message","text":"ping","user":<redacted>,"team":<redacted>,"blocks":[{"type":"rich_text","block_id":"tHJFI","elements":[{"type":"rich_text_section","elements":[{"type":"text","text":"ping"}]}]}],"user_team":<redacted>,"source_team":<redacted>,"channel":<redacted>,"event_ts":"1573030640.004600","ts":"1573030640.004600"}}

Are there any problems now with the new slack version, so they send a different kind of event now or something?

[nazariinovak]

It looks like before, this was the struct that parsed the incoming event https://github.com/nlopes/slack/blob/master/messages.go#L16-L20

But slack changed the type "message" object to {"client_msg_id":<redacted>,"suppress_notification":false,"type":"message","text":"ping","user":<redacted>,"team":<redacted>,"blocks":[{"type":"rich_text","block_id":"tHJFI","elements":[{"type":"rich_text_section","elements":[{"type":"text","text":"ping"}]}]}],"user_team":<redacted>,"source_team":<redacted>,"channel":<redacted>,"event_ts":"1573030640.004600","ts":"1573030640.004600"}?

[cilla-md]

Info from slack: However, it does seem that the culprit is with changes to the message payloads due to the WYSIWYG change and that was mentioned in our change log here indicating that you'd start to get "type": "rich_text_section" in your payloads:

https://api.slack.com/changelog/2019-09-what-they-see-is-what-you-get-and-more-and-less

[DenKoren]

It seems that fix is already in master, but not yet tagged. The current behaviour of v0.6.0 makes work with messages impossible through RTM IncomingEvents. Is it possible to put patch to actual v0.6.0 version and tag it with v0.6.1 to make code work as a quickfix?

The problem is caused by 'rich_text' block that is considered 'unknown' by v0.6.0. This causes "unsupported block type" unmarshalling error

[nazariinovak]

Can confirm that it works with the latest version from master

[DenKoren]

Yes, the fix is in block_conv.go file in switch expression where the block type is detected.

// UnmarshalJSON implements the Unmarshaller interface for Blocks, so that any JSON
// unmarshalling is delegated and proper type determination can be made before unmarshal
func (b *Blocks) UnmarshalJSON(data []byte) error {

		...

		switch blockType {
		case "actions":
			block = &ActionBlock{}
		case "context":
			block = &ContextBlock{}
		case "divider":
			block = &DividerBlock{}
		case "image":
			block = &ImageBlock{}
		case "section":
			block = &SectionBlock{}
		case "rich_text":
			// for now ignore the (complex) content of rich_text blocks until we can fully support it
			continue
		default:
			return errors.New("unsupported block type")
		}

To fix problem in v0.6.0 the

		case "rich_text":
			// for now ignore the (complex) content of rich_text blocks until we can fully support it
			continue

is enough to be added to that switch, exactly like it is done in master.

[DenKoren]

Unfortunately I can't make a PR to your repo since it is required to have target branch existing for PR. If I understand the versioning flow of this project correctly, to fix the bug we need:

git checkout v0.6.0 // checkout to the tag
git cherry-pick c4750fe73d883a2b1edff13e0d2e09290512b405 // copy the fix from master to current branch
git tag v0.6.1 // bump version
git push --tags // push the changes into github

[SmilingNavern]

It's fixed in #618 and latest master works fine. Would be great to have tagged release for this.