Feature Request: Async api for receiving messages

[HKalbasi]

Using async/await instead of manual state machine can dramatically simplify code. For example the Dialogues management example in the readme can become something like this:

loop {
    let chat = bot.accept_new_chat().await?;
    tokio::spawn(async move {
        chat.send_message("Let's start! What's your full name?").await?;
        let full_name = chat.receive_message().await?;
        chat.send_message("How old are you?").await?;
        let age = loop {
            let age = chat.receive_message().await?;
            match age.parse::<u8>() {
                Ok(x) => break x,
                Err(_) => chat.send_message("Send me a number").await?,
            }
        };
        chat.send_message("What's your location?").await?;
        let location = chat.receive_message().await?;
        let report = format!("Full name: {full_name}\nAge: {age}\nLocation: {location}");
        chat.send_message(report);
        // chat is dropped, next message from this user will trigger `accept_new_chat` again.
    });
}

Pros

• It enables expressing bot logic in a linear, dense, and more readable way.
• It enables code reuse in ways that are hard/impossible currently. For example a we can have a prompt function to do send_message + receive_message, or extract the loop in the example above as fallible_prompt("Send me a number", |x| x.parse::<u8>())

Cons

• In this way we store the state in the tokio task local variables, so we will lose it on bot restart. This tolerable in most cases, and sometimes even desired. We can always manually store things in the persistent storage in important checkpoints, and use this api for short dialogs.

[Hirrolot]

In this way we store the state in the tokio task local variables, so we will lose it on bot restart. This tolerable in most cases, and sometimes even desired. We can always manually store things in the persistent storage in important checkpoints, and use this api for short dialogs.

Consider what happens when a bot gets restarted, which can happen due to some server error or if you decided to update the code. In this case, a user should not notice anything, but with the approach you've suggested the dialogue will be removed from memory and lost forever. From the point of a user, it'd look like a bug.

It's true that .await is much more readable and declarative though. In essence, .await can be described as a finite state machine (I remember there even was a macro for that back in the old days). However, I wasn't able to figure out how to exploit .await to make it compatible with persistent dialogues.

Also, the approach of saving the dialogue state in certain points is error-prone -- we can just forget to do that. On the other hand, the current approach with FSMs does it automatically behind the scenes.

[WaffleLapkin]

I think what @HKalbasi is trying to highlight here is that dialogues are usually short lived, so in a lot of cases it does not matter much if we lose it. (the probability to loose it mid dialogue is lower because it's short lived, it can be redone easily for the same reason, etc)

[HKalbasi]

And it doesn't need to replace the current api, just complement it. For long dialogues or cases that persistence is very important, users can always use the current api.

[WaffleLapkin]

I think my biggest concern here is that this requires quite a bit of design & implementation work. Given our capacity I don't think we'll be able to get to it anytime soon.

But it does look like with enough work & workarounds, this should be possible to implement. So, maybe one day :)

[Hirrolot]

I think what @HKalbasi is trying to highlight here is that dialogues are usually short lived, so in a lot of cases it does not matter much if we lose it. (the probability to loose it mid dialogue is lower because it's short lived, it can be redone easily for the same reason, etc)

A sudden interruption of the control flow can still look like a bug though. If a bot has enough users, this will certainly be noticed at some point.

My other concern is having two alternative implementations of the same idea. What usually happens is that users prefer the nicer-looking solution, then (some part of users) stumble upon the limitations of the basic solution, then rewrite the logic to use the more advanced solution. We already have it in the form of REPLs/dispatcher. Having it also for dialogues/.await points means that once a user of the library decides to use state machines instead of .await, they will need to rewrite almost the whole bot logic (in addition to breaking library changes). Having FSM-based logic right from the beginning would thus save time long-term.

Other than that, I agree with @WaffleLapkin that we don't have the capacity to implement it anytime soon.