Conversation
| thread_ts = get_block_thread_ts(incoming_message) | ||
| # TODO (george) not sure this is always what we want, unfortunately. Some bots may want to keep a | ||
| # conversation going through threads, others may not? | ||
| context_id = chat_id if not thread_ts else f"{chat_id}-{thread_ts}" |
There was a problem hiding this comment.
Possibly an advanced configuration option for this class.
There was a problem hiding this comment.
Agree that this could be a nice config option.
Just thinking out:
- If the inbound message was already in a thread, it seems Always Right to respond in-thread.
- If the inbound message was not already in a thread, maybe that's when some kind of
always_thread_responseoption would dictate?
There was a problem hiding this comment.
Oh, that's not even what I was meaning to discuss here but that's a good point and I will chase that.
The thing I was getting at here is that build_default_context IIRC will be used for recalling previous messages from a file using that ID, and I wanted to consider whether, if you're talking to the agent from within a thread, the requests to the bot from the outer channel should be considered (ETA: and from within other threads for that matter)
eob
left a comment
eob
left a comment
There was a problem hiding this comment.
This looks awesome! A few small requests w/r/t where you can stash some constants.
Excited to start using this in our own bots :)
| thread_ts = get_block_thread_ts(incoming_message) | ||
| # TODO (george) not sure this is always what we want, unfortunately. Some bots may want to keep a | ||
| # conversation going through threads, others may not? | ||
| context_id = chat_id if not thread_ts else f"{chat_id}-{thread_ts}" |
There was a problem hiding this comment.
Agree that this could be a nice config option.
Just thinking out:
- If the inbound message was already in a thread, it seems Always Right to respond in-thread.
- If the inbound message was not already in a thread, maybe that's when some kind of
always_thread_responseoption would dictate?
|
Still going to give this a bit of ad hoc testing before merge |
… them strings for ease of reading plaintext
|
Sorry for churn, found a couple of issues (didn't realize config values stripped Enum-ness so comparisons failed) E: but now it doesn't look like it in tests? Blerg |
2 participants
Adds knowledge of threading to the Slack Transport.
In its current form, the transport will respond to the channel ID only, which means that if you respond from a thread the transport will respond outside of it. This adds knowledge of the
thread_tsfield to blocks, which is thetsof the parent message in the thread, and is specified in thechat.postMessagemethod as a way to reply to it.Some open questions about whether context ID for the bot context should be channel or (channel,thread) tuple.
I've also noticed that the Tags representing slack metadata on those blocks seems to be getting stripped on its way down to the tool, which I'm assuming is defined behavior but I haven't traced it yet.