Wee-slack: [BUG] replying to a threaded message

[carnott-snap]

Given the following channel actions:

id | parent | text | command
-- | -- | -- | --
45a | #general | ask topic question? | /msg #general ...
d18 | 45a | propose answer | /reply $45a ...
0f1 | 45a | rebut answer | /reply $45a ...
59d | 0f1 | rebut rebuttal | /reply $01f ...
29f | 0f1 | acquiesce | /reply $01f ...

wee-slack actually displays things like I would expect:

one | ask topic question? [ Thread: 45a Replies: 2 ]
two | [45a] propose answer
one | [45a] rebut answer [ Thread: 0f1 Replies: 2 ]
two | [0f1] re, which is the command that `two` executed. Ibut rebuttal
one | [0f1] acquiesce

However this is not what the web ui shows, one must /slack rehistory to get that view:

one | ask topic question? [ Thread: 45a Replies: 2 ]
two | [45a] propose answer
one | rebut answer [ Thread: 0f1 Replies: 1 ]
two | [45a] rebut rebuttal
one | [0f1] acquiesce

Notice that two is able to convert 0f1 from a thread to channel message, even though one sent and owns the message. This to me smells of a slack api bug, but I am not familiar enough to accurately report it.

For correctness, it would be nice if /slack rehistory did not change the data model, but I am unclear how feasible this is:

• If this is an antipattern, we can disable /replying to thread messages.
• Else if the reply atomically causes the visibility change:
  
  
  
  • Place 59d on thread 45a not 0f1, even though the user requested it.
  
  
• Else:
  
  
  
  • Make the api call that promotes 0f1 to #general.
  
  
  • This also seems like a cool power user feature: /slack promote $0f1.
  
  
  • Modify 0f1 to have parent #general.
  
  
  • Have 59d thread off 0f1.
  
  

[trygveaa]

Yeah, this most definitely seems like a bug in slack since even the web client will show different contents in the thread depending on if you have the client open while sending these messages or if you open/refresh the client afterwards. If you have it open, 0f1 will be in both the thread and the channel and 59d will be in both threads.

If this is an antipattern, we can disable /replying to thread messages.

This is the fix we should do, since I'm pretty sure this is a bug in the API, and since you're not allowed to reply to thread messages in the web client.

Place 59d on thread 45a not 0f1, even though the user requested it.

I don't think that is a good idea, since it might be surprising to the user. However, we could make the R command in cursor mode (I assume that's how you managed to do this?) use the parent id instead of the message id when you trigger it on thread messages.

[trygveaa]

I submitted a bug report for it to Slack. I'll wait to see how they resolve it before making any changes to wee-slack.

[carnott-snap]

However, we could make the R command in cursor mode (I assume that's how you managed to do this?) use the parent id instead of the message id when you trigger it on thread messages.

I am using right click with mouse mode, to get the message $id, and sending a /reply $id ... command directly. I am unclear what the R command is, but would want to ensure that the _right click_ operation returns the message id, not the parent, since other actions (e.g. $ids/a/b/, $id+:+1:, etc.) do not have the restrictions that /reply does. It seems like reply needs to do this gymnastics internally, much like how it converts /reply 1 ... into a valid message id.

[trygveaa]

Ah, I didn't think about mouse mode. Yeah, you're right, doing it in the /reply command is probably the way to go.

Btw, Slack said they have reproduced the issue and filed a bug report internally.

[trygveaa]

Replying to a thread message now posts the reply in the same thread as the message you reply to.

Btw, Slack said they have reproduced the issue and filed a bug report internally.

I haven't heard from them since they said this, but the issue I filed is still open. But since we no longer send in the ts for a thread message as thread_ts (this is what happened when you replied to a thread message), it doesn't really matter how Slack handles it. They also said that it is an error to do so btw.