Slack threads and chat integration plugin transcripts

Continuing the discussion from Set up Slack notifications using the discourse-chat-integration plugin:

Just tried typing /discourse post in a Slack thread and got this response:

/discourse is not supported in threads. Sorry!

Interestingly though, typing /discourse post in the normal channel composer does pick up messages from within threads.

I also tried creating two threads and then alternating posting messages in each thread.

Then, when I did /discourse post 10, the transcript created had each of these messages interleaved…


@david - I was trying to post a transcript today and the way the plugin currently handles threads makes it pretty challenging.

It can make it feel like the messages in the transcript are almost completely out of order.

Do you have any insight into how hard it would be to make some improvements in this regard?

Some ideas for options for handling threads would be:

  1. If you post the slash command from within a thread, just grab the whole thread and nothing else
  2. (A) If you post from the main channel, skip messages in the threads
    (B) If you post from the main channel, show messages in threads indented underneath the first message

I feel like threads in Slack are so disastrously bad that there is no winning in this scenario.


I’ve definitely seen them be disastrous. Until recently, I felt exactly the same way… that there was simply no hope (transcripts aside).

But recently, I’ve seen people adopt some patterns that seem to work. There are some channels where now most discussion takes place in threads (the main channel almost looks like a topic list).

So I think there is room for improvement, and I’m curious whether @david knows any more about what may be technically feasible given his familiarity with the plugin code and the Slack API.


I had a look at the API. It looks like we can’t specifically request messages that are/aren’t part of a thread. As you have noticed, messages are simply loaded in chronological order regardless of what thread they’re in. This can lead to a lot of mess!

When we retrieve messages, we are told whether they are part of a thread. So that means it’s definitely possible to filter them out on the discourse end, meaning that the transcript would only contain messages that are part of the “main” conversation. We would need to be careful to include those messages that are “broadcast” out of a thread into the main channel.

As for posting a transcript of a thread - as far as I can see, custom slash commands aren’t supported in threads… So that’s not a great start! This is the only mention of the issue I can find.

So to go back to your list:

I don’t think this is possible, because slash commands don’t work in threads :frowning:

I think we can do this fairly easily :slight_smile:

This would be cool. How long do your threads tend to last? If the first post of a thread is more than 500 messages in the past then we might have an issue… And that 500 includes all posts in all threads that are part of a channel.

Tl;dr: Threads in Slack seem like a bit of an afterthought as far as the API is concerned!


Hmm… Sounds like it. thanks so much for the thorough notes on what you’ve found.

I haven’t seen many threads with more than 20 messages, so I think this would work out pretty well.

The bigger issue I see is actually something like this:

  1. user posts message
  2. others respond as a thread
  3. many more messages in main channel
  4. another response in thread from (1).

If there’s a lot of message in between in step (3), than the message in the thread from step (4) might get missed. (Or another way to put it is that I’ll have to include a bunch of junk from (3) that I might not care about just to get the message from (4).

That’s a bummer. As you said, seems like their API could use some love. But I think this option (B) would come the closest to behaving in an “expected” way for people that use threads.


I just found this part of the Slack API which I missed before:


So I think that means, given the start message, we can load its replies. It will require an HTTP request for every individual thread, which isn’t great, but since we are deferring the transcript processing anyway it might be ok.

Implementing that is achievable, but will be a fairly large amount of work.

In the meantime, here is a PR ignores any “thread replies” in a transcript. So given a slack channel like this:

The transcript will look like this:

This should prevent any weird issues where thread messages are being interspersed with main channel messages.


Hey David!

Something I’ve noticed every so often is that Slack messages come in out of order. This occurs when multiple posts happen near the same time on Discourse, they sometimes are posted to slack in a different order. This can be confusing if both posts were from the same topic - the reply is posted in Slack above the post that was replied to.

Message sending jobs are queued on sidekiq in the same way as email sending jobs - so as soon as the post is created, a job is scheduled X minutes in the future.

I guess sidekiq doesn’t guarantee that scheduled jobs are run in sequence…

Not really sure what the solution is here - is this a problem solved anywhere else in discourse?


This is a very minor issue @david, only applies to very rapid responses, and can be ignored.

I also personally do not find it very confusing at all. If the two messages are super close in time, seeing them out of order is not a big deal.


Just bumping this again since I used the transcript feature today. It was very helpful, but I did have to go in and manually insert some of the threaded messages myself. Thread adoption is real at our place, so still would love to see this at some point…

As seen on ember forums:

We continue to see adoption in our Slack instance, with many channels explicitly encouraging/demanding that people keep conversations in threads.

I’m honestly not sure if we would post any more transcripts from Slack if the feature supported it, but there are many cases now where I know we can’t really use it as is…

1 Like

Unfortunately Slack still don’t support custom slash commands in threads, so we’re stuck with performing the slash commands in the context of the main channel :frowning:

The main problem we have with implementing thread support with a UI is obtaining human-readable names for each of the threads in the channel. If the thread starts more than 500 messages in the past, there is no way to get a sensible name without an additional HTTP request.

Judging by their API page, it looks like Slack have started implementing fairly strict rate limits for third parties. If we’re making many HTTP requests to fetch thread titles, then we’re going to hit the 50 req/min limit pretty quickly.

However, we could do something like this pretty easily:

/discourse post thread https://<slackname>

(the URL is the slack thread URL)

We could skip the ‘start/end message’ UI, and just put the whole thread in the transcript.

The obvious problem is that it’s quite ninja, and not particularly pretty. What do you think @mcwumbly, do you think it would still be useful?

Can we stop blocking the word thr3ad yet? I just had to edit 8 legitimate occurrences in this post! :stuck_out_tongue:


I think it’s hard to say. If it were available, I’d love to try it and see.

A small tweak to suggest would be to just do this if the URL matches a message within a thre4d, (something with thread_ts in it, e.g.:

/discourse post

I’ve added basic support for threads to my other pending PR (changes the same bits of code):

Either syntax can be used:

/discourse post thread https://<slackname>


/discourse post

In both cases the “first/last message” UI is skipped - the entire thread is included in the transcript.


I think one option we would be open to is a pr that allows you to set which TL has particular blocked words, cause blocking thread from tl0 and 1 is pretty much our intent here, plus we want to make the feature better, and there are tons of missing refinements here that are missing, like teaching people why a word is blocked (optionally) vs just saying sorry, not allowed



Anything holding back this PR in particular? Or is it just the normal other things have been higher priority situation?

Eager to try it out!

1 Like

Sorry for the huge delay here. We stopped using Slack internally so testing changes like this is hard. PR is merged.


Hey @david - Just got a chance to try out the new feature to post threads… looks like it’s not quite working or us.

I tried each syntax or a couple different threads, but just get this in response:

Loading the transcript…

Using the normal command continues to work as it did before, though.

Also, when I tried posting a transcript from a private channel, I got this:

Darn - that slash command didn’t work (error message: 422_client_error). Manage the command at Discourse

I looked at the diff from the PR and thought perhaps it’d be necessary to add the conversations:history scope to the app on Slack, but I didn’t see that as an option. I tried adding the groups:history scope instead, but that did not seem to work.

Let me know if there’s anything else you’d like me to try for either of these issues. Thanks!