Message::filter_reply_to_message() overrides the original message

[WaffleLapkin]

Originally reported in #750.

Message::filter_reply_to_message() inserts a Message into the dependency map, this message overrides the original message. This makes it impossible to use Message::filter_reply_to_message() and retrieve both the original message and the message original message replies to.

A temporary workaround is to use dptree::filter_map with a new type, as follows:

use teloxide::dptree::filter_map;

struct Reply(Message);

// ...
.branch(filter_map(|m: Message| m.reply_to_message().cloned().map(Reply)).endpoint(reply_dispatcher))
// ...

pub async fn reply_dispatcher(bot: Bot, msg: Message, Reply(reply_to_message): Reply) -> ResponseResult<()> { /* ... */ }

Meta

• teloxide version: 0.11.0

[Hirrolot]

That's the thing I thought about for a while as highly unlikely while designing dptree, but it eventually sprang out lol.

Indeed there's a bit of undocumented gray area here. Possible solutions on the site of dptree:

• Prohibit appending a dependency if its type is a type of some other dependency in the context.
• Emit a warning if so. (Don't like this solution, since it's not about semantics.)

Possible solutions on the site of teloxide:

• Wrap dependencies in type wrappers (which ones?)

[TmLev]

axum v0.6+ allows you to specify state needed by a handler as regular function arguments and do so in a compile-time fashion, erroring out when the state wasn't provided:

• https://tokio.rs/blog/2022-08-whats-new-in-axum-0-6-0-rc1#type-safe-state-extractor
• https://docs.rs/axum/0.6.0-rc.2/axum/index.html#sharing-state-with-handlers

Maybe this can help with the dependency map of dptree.