It seems there's a (work in progress) library that implements an interface for Slack's SocketMode called slacker. It implements some of the features we need (e.g. handle "disconnect" events).
We should try replacing our websocket loop with slacker.
Clarification and motivation
Right now, we have a websockets application that consists of a simple loop (see TzBot.Slack.SocketMode.Client.wsApp): it waits for a message, reads it as Text, prints it to stdout, repeat.
Here's what the loop should do:
[ ] Receive and parse a Slack Event
[ ] Send an "acknowledgement message" for each received message (see docs)
[ ] If we receive an event with "type": "message" (see the next section), we construct a EventSummary and run processEvent asynchronously.
[ ] If we receive an event with"type": "disconnect" (see docs), exit the loop, establish a fresh websockets connection and re-start the loop.
All messages delivered via websockets (aka Slack's "Socket Mode") are wrapped in an "envelope" (docs).
Inside that envelope, you'll find an "event wrapper", whose format is described here.
Inside that event wrapper, we'll find the actual event info. In this case, we're only interested in "message" events (see docs).
Some of those "message" events may have an optional "subtype": "message_changed", indicating that a message has been edited (see docs). Those events will have a previous_message field with the "old text" before it was edited. The docs seem to be incomplete in this regard, they don't mention this field, but you can see it in the example jsons above.
Note that we don't have to parse all the fields. Only the ones necessary to build an EventSummary.
Acceptance criteria
We have a websockets loop capable of dispatching to processEvent when a new event is received.
UPDATE:
It seems there's a (work in progress) library that implements an interface for Slack's SocketMode called
slacker. It implements some of the features we need (e.g. handle"disconnect"events).We should try replacing our websocket loop with
slacker.Clarification and motivation
Right now, we have a websockets application that consists of a simple loop (see
TzBot.Slack.SocketMode.Client.wsApp): it waits for a message, reads it asText, prints it to stdout, repeat.Here's what the loop should do:
"type": "message"(see the next section), we construct aEventSummaryand runprocessEventasynchronously."type": "disconnect"(see docs), exit the loop, establish a fresh websockets connection and re-start the loop.Parsing events
Example jsons:
All messages delivered via websockets (aka Slack's "Socket Mode") are wrapped in an "envelope" (docs).
Inside that envelope, you'll find an "event wrapper", whose format is described here.
Inside that event wrapper, we'll find the actual event info. In this case, we're only interested in "message" events (see docs).
Some of those "message" events may have an optional
"subtype": "message_changed", indicating that a message has been edited (see docs). Those events will have aprevious_messagefield with the "old text" before it was edited. The docs seem to be incomplete in this regard, they don't mention this field, but you can see it in the example jsons above.Note that we don't have to parse all the fields. Only the ones necessary to build an
EventSummary.Acceptance criteria
processEventwhen a new event is received.