I moved 28 messages from one channel to a new one and they all went out of order:
Thanks for reporting this, I did try to take this into account with the feature but I think I got a little too lucky with the testing I did So we do indeed set all the timestamps to the same thing here:
The problem is that we do not want to interleave the moved messages between the existing channel messages, and it gets harder and harder the more messages your move.
A question before I dive too deep on this – can you remember and identify which messages are out of place? Is there just a couple, or are they completely out of order? I think what has possibly caused the discrepancy is that when we are fetching messages for a channel, we do it by ID order (which we order DESC and then reverse in most cases):
Whereas in the message mover I am ordering by
created_at to maintain order, which could cause some small discrepancies:
I have some ideas on how we might be able to address this (maybe changing the message mover to order by ID or changing the controller to order by
created_at would be enough, preferring the latter because I think it would make more sense), but I would like to hear just how messed up the order is if it’s possible to tell.
I un-deleted them from the original channel after I noticed they were jumbled in the new one. I should be able to quote them in order here:
I wonder when it’s preferable to move messages rather than quote them. Perhaps it depends whether there is an existing topic or not? Not sure. In what scenarios would one of the following be better to nudge people towards?
- Quote chat messages in existing topic
- Move chat messages to an existing topic
- Quote chat messages to a new topic
- Move chat messages to a new topic
Since strings of chat messages are, erm, more “chatty” than topics, I have some sense that we may want to encourage quoting more than moving, in general.
Are there cases folks have observed or have in mind where you’re like, “nope, quoting would not be good here. definitely need to move them instead.”?
If you just quote the discussion can be continued in two places.
@Moin are you suggesting that moving messages would be preferable when you really want to avoid that?
Thanks for doing that – that’s completely jumbled up! I will have to do some local testing on larger message sets. I think at the very least this will be needed:
I am generally uneasy about ordering by ID though because of weird inconsistencies, I think ordering messages by
created_at would be better generally for the channels. @joffreyjaffeux or @mcwumbly what are your thoughts on this? If we decide to do that then the message mover might need to artificially space out the
created_at values by 10ms each or so for consistent ordering.
I think in general if they are totally irrelevant to the current channel it would be better to move to a more appropriate channel. We used this many times previously internally when we used Mattermost. For example, a bunch of incident response in the
general channel that should be moved into the
incident channel for better record keeping. Or, idle chatter in a channel that is better to be in the
I don’t think there is any value in those cases of quoting and leaving old cruft behind, and as Moin says, things can then be confusing, where the discussion is continued in two different places.
Keep in mind these two options do not currently exist. We removed “Move to Topic” because in the initial implementation it was making one post per chat message, and also not deleting the original messages in the channel. If in future we want to make this again it needs to:
- a) quote batches of messages together (say 100 per post) using the chat quote feature and
- b) delete the originals in the channel to avoid duplication.
I’ll abstain from commenting on the implementation for ordering posts and let @joffreyjaffeux comment on that aspect of things.
Ah, yeah. I wasn’t asking about moving chat messages within chat, but I can see how that can be useful, and it doesn’t have the problem of trying to convert short-form into ling-form (or vice versa) “in post”.
Makes sense. I like the general form of quoting as more of a “transcript” like this because I think it’s likely going to read that way anyway. In the past, when I used the Slack transcript feature, I often found myself wrapping it in
[details] as well, and summarizing things in the main post body.
Another thought I had along those lines might be to have a fancier “expand context” feature, so you could quote a single message, but then load additional messages inline on demand to view more context from chat without leaving the topic.
I’m skeptical about this part being necessary or valuable when referencing discussions across the slow lane/fast lane boundary.
It’s only if you’re choosing Move to Topic that this would happen, why keep things around in the channel if your intention was to move it? We have had some discussions around this internally already. Sure just a normal quote of messages into a topic would not delete anything.
Some trivia for you, the class that generates the quotes is actually called
This is interesting, we actually do have something similar to this with our topic quotes (you probably already have seen that). It would probably be useful to get a little more context without having to actually visit the channel.
I would say the use case for moving is:
- We have a channel dedicated to discussion about “Whales”
- A bunch of people start having a an involved discussion about “Penguins” cause they forgot to click “#penguin” and stuff got heated
- Mod steps in and kicks the Penguin talk to the Penguin channel.
I guess the fundemental thing here is the re-sequencing.
I would say “fudge created_at” is about the only sane solution here cause you want everything moved in one block? Plus it technically is created at the point of time it is moved.
Yeah, I think I’m wondering whether it’s needed, or if quote/transcribe is the thing to focus on making work really well.
Yes I would 100% do this if our normal GET messages route for a channel was ordered by
created_at, that’s what I want to sort out, was just wondering if Joffrey had some historical knowledge about that. If not will change both things at once.
Yes Im 100% with sam and you😁 Moving everything in one go and giving it the created_at of the time of the move is the only sane approach IMO. Otherwise it opens a gigantic can of worms… how do I know where to find it? receiving unread notifications for things created before my last read? nope nope nope
Nice, I will tweak the move tool to the moved messages be in the future with a small spaced out increment, and make the chat messages order by
created_at instead of ID in the general controller
Just merged this to hopefully address the issue:
I didn’t do anything to artificially space out
created_at for now into the future, so let’s see how this goes first.
This topic was automatically closed after 11 days. New replies are no longer allowed.