fenhl/rust-racetime

A Rust library to help you create chat bots for racetime.gg

This is a Rust library to help you create chat bots for racetime.gg.

Some of the code is based on the Python library at https://github.com/racetimeGG/racetime-bot.

rust-racetime's Issues

cannot test against local instance because of various host/protocol/etc handling

This method just has https hardcoded, which isn't great for testing this locally:

https://github.com/fenhl/rust-racetime/blob/main/src/lib.rs#L77

It doesn't appear to be possible to specify a port to run on because of this line:

let (ws_conn, _) = tokio_tungstenite::client_async_tls(request, TcpStream::connect((&*data.host, 443)).await?).await?;

(https://github.com/fenhl/rust-racetime/blob/main/src/bot.rs#L162)

which requires both that data.host is just a hostname, and that we are using port 443

I'm sure I'll run into more (I see a wss:// hardcoded somewhere).

Would you be interested if I put together a patch for this?

How to use the results of (for example) gethistory?

I am trying to write some code that does something like the following:

1. when a new race is registered, send a gethistory command[0]
2. wait on the result of that command
3. send a new message based on the results of that command

This seems to be very hard with the way this library currently works. The new handler must return before the chat_history handler is called. This is reasonable - the natural approach to this constraint is to run your race handler code in a separate tokio task and communicate with channels.

But I then run into another issue: if I have a separate task that's doing the handling, it can't actually send messages, because I only have access to the &RaceContext<T> during the execution of the callbacks.

now, the &RaceContext<T> has a perfectly cloneable pub sender: Arc<Mutex<WsSink>> but I would much rather use the convenience methods (.send_message(), etc).

Am I missing something? Is there a good solution here?

If I'm not, do you have any ideas for how to solve this? One that occurs to me is to split out the send-messages-to-the-race-room functionality into a separate struct, call it like RaceSender. a RaceSender can be a thin wrapper around the Arc<Mutex<WsSink>> with the convenience methods, and then it can be #[derive(Clone)] and consumers of the library can grab it as necessary.

Thanks!

---

[0] The reason for this, in case it's relevant, is that I want the bot to be robust to restarts. On a restart it will rejoin all the rooms it was already handling and I'd rather it not repeat itself. Obviously I could handle this by persisting state somewhere, but it doesn't seem like that should be necessary. And in general, having a non-reactive handle to send messages to a race room seems like a reasonable ask.