Background tasks with access to rocket state (Specifically database conn)

[tehsmeely]

Setup

I have a Rocket application which serves a bunch of challenge progress to users from the database.
The challenges are updated by querying an external (3rd party) API, processing the responses and then updating the database state. This needs to happen periodically and continuously, ideally via some scheduled background task.

In theory this can be done entirely in isolation of the rocket app, but it would be very nice to share as much handling code as possible (and leave the potential for other non-polling behaviour like webhooks for the api for which the rocket app).

Problem

However I can't see a way to schedule any tokio tasks that have the right kind of access to create a [rocket_sync_db_pools::Connection] (which is generated so the type is pretty hidden too) or otherwise trigger the request guard to create the database connection.

Question

Basically I want to spawn some repeated tasks which can access Rocket state akin to request guards in order to acquire the same DB Connection.
Is there some neat way for me to do this that I'm missing? Is there a neat workaround? Or do i need to bite the bullet and write some custom code to re-establish a duplicate postgres db connection and generalise my handling code to either use the Rocket DB connection as well as my non-rocket one?

[bubelov]

I had the same problem and I ended up using r2d2 pools directly, plus my own cron-based loop which utilizes async version of sleep between scheduled tasks. Coupling your own scheduler with Rocket might not worth it, even if it's possible, given the only thing you want to share is a connection pool. Pools are cheap, and even if both of those components also share a few functions, that should be fine too, as long as those functions accept single connections instead of pools (they'd have the same type no matter which pool they're coming from). Using Rocket-focused connection pool outside of Rocket wouldn't make much sense anyway. Hopefully someone can provide more information on the possibility of neatly integrating schedulers within the Rocket itself. Again, it's not in the docs so I wouldn't put much hope on that being possible

[jebrosen]

I think this is essentially issue #1187.

rocket_sync_db_pools does not currently have this capability and I'm generally in agreement with @bubelov on adding your own secondary database pool given this limitation. It is likely possible to implement this, but it might necessitate even further redesign on top of the async compatibility work.

Instead, we focused efforts on direct support for async database pools (including deadpool-postgres and sqlx) in a new crate rocket_db_pools*. One of the goals for rocket_db_pools was to solve this exact limitation! The database type now implements Deref to the underlying pool type, so one could call SomeDb::fetch(&rocket).clone() to get an independent handle to the connection pool which can be sent to other tasks/threads. Overall, rocket_db_pools has fewer limitations than rocket_sync_db_pools and is going to be a better choice for databases with an async driver available.

*(currently only in the master branch, not yet published on crates.io)

[tehsmeely]

Thanks folks, I'll implement my own pools like you suggest - and keep my eyes peeled for rocket_db_pools!