slackbot: module

[scarlettperry]

Description

PR adds the building blocks for the module that interfaces with the Slack API

• receives & processes the request from Slack
• sends the users's message to the bot service, where it's mapped to a reply (for now, just Hello, World! or a default help message)

Testing Performed

Locally

App Mention Event (ie messaging bot in a slack channel)

IM Message Event (ie messaging bot in a DM)

GitHub Issue

#8

TODOs

Example:

• separate ack'ing the slack request and handling the event
• unit tests

[scarlettperry]

@danielhochman still need to add unit tests but can I get some early feedback? I've kept the bot service really simple for now till i get to the grpc reflection step. Also, lmk if you'd like me to break some parts of the flow into different PRs.

Something I'd like your thoughts on is async processing. Slack docs recommend separating the process of (1) acknowledging receipt of the request and (2) handling the event. In the PR, I left a comment to denote at which step we can do this (after we've verified it's a request from Slack and after we've checked if it's a URL verification event).

We receive 1 event in each request so some thoughts:

• a simple job queue. create an event channel and start a worker goroutine
• i need to look at the audit service code more closely but perhaps something similar in how it passes an event to the audit sink which does whatever it wants with it

do you have something else in mind?

Lastly, a topic we can have a converstation on later but wanted to raise: dropped events. Are some dropped events okay? Do we want to persist in memory or externally somewhere (SQS, Kafka)? Just something I've been thinking about.

[danielhochman]

a simple job queue. create an event channel and start a worker goroutine

yep this sounds good

Lastly, a topic we can have a converstation on later but wanted to raise: dropped events. Are some dropped events okay? Do we want to persist in memory or externally somewhere (SQS, Kafka)? Just something I've been thinking about.

for now, just drop them on the floor, not worth any extra complexity as long as we're doing straightforward read-only request/response commands. later on we may use postgres as a queue layer similar to audit if we require durability.

[scarlettperry]

PR's getting big. Going to break out the proto changes and service in separate PRs, and this will just have the module flow.

[mikecutalo]

Have you thought about capturing some metrics? Maybe success and failure when handling events?

[scarlettperry]

Have you thought about capturing some metrics? Maybe success and failure when handling events?

yep! meant to add a TODO, thanks for the reminder. In a followup PR will collect some metrics

[danielhochman]

delete or add more info

[scarlettperry]

added more info and moved this log lower in the flow when we've confirmed if its an app mention/DM event

[scarlettperry]

left a todo on getting the channel/user name b/c the ids are not really helpful. we can use these ids to make separate slack API calls to get the channel/user name. though, then we'd want to cache the results to avoid having to make these calls each time there's an event and to avoid getting rate limited by those APIs

[scarlettperry]

a few todos in the PR. I'll create issues for some, maybe we'll get contributors :)