Add `re_received` Flag to Enhance Thread Reply Detection

[kato-mahiro]

Overview

This PR introduces a new boolean flag, re_received, to the callback function of the SubscribeToChannelMessages class, aiming to improve the detection of messages that are received again as a part of thread replies. This enhancement addresses the need to distinguish between new message posts and re-received messages due to activity in their associated threads.

Background

In practice, I've encountered a recurring issue where the new messages in a thread trigger notifications, and the thread's initial message gets re-sent every time. This redundancy has been problematic, cluttering the message flow and complicating message handling logic. To resolve this, a clear way to identify re-received messages became necessary. Hence, introducing the re-received flag aims to tackle this issue precisely by allowing for the differentiation of messages and ensuring that only relevant messages are processed further.

[kato-mahiro]

Example

Suppose a message has received two replies within a thread like this.

In this situation, I can receive messages like this.

This PR helps to distinguish re-received messages.

[hynek-urban]

Hi @kato-mahiro, thanks for this PR! In my own usage, I have dealt with this case by remembering which messages were already handled (by remembering their IDs).

Do you see the new flag adding some value compared to this other approach?

[kato-mahiro]

Hi, @hynek-urban

Thanks for your feedback on the PR. While tracking message IDs is a valid approach, it introduces additional complexity and maintenance overhead, especially for simpler bots that perform thread replies. The re_received flag proposed simplifies identifying re-received messages without external state management, making the bot's logic more straightforward and maintainable.

This solution reduces the need for a database or file system to track message IDs, streamlining the development process and minimizing potential bugs. It's particularly beneficial for developers aiming for simplicity and efficiency in their thread-reply bots.

I appreciate your consideration and am open to discussing this further to find a solution that benefits the project.

[hynek-urban]

@kato-mahiro That makes sense! You're right that without a database of some sort, the already handled message IDs would not survive bot restarts.

The last thing before I merge this - would you mind renaming re_received to something like repeated or is_repeated? Or maybe even repeated_due_to_reply if we wanted to be explicit :)

[kato-mahiro]

@hynek-urban Thank you for your valuable feedback and suggestions! Based on your advice, I've updated the flag name from re_received to repeated. Please let me know if there are any further adjustments needed.

[hynek-urban]

Great, thanks :)