zeroassumptions / aide-de-camp Goto Github PK

Any reason id is of type Xid instead of String? https://github.com/ZeroAssumptions/aide-de-camp/blob/92aea347f69950a3d0f081e6590d47d73331bd1b/aide-de-camp/src/core/job_handle.rs#LL11-L11C25

Some database such as surrealdb will efficiently store UUID. While this would be breaking change it would be good if the id was of type String.

Are there plans to add support for cron?

Could be useful when the Job is scheduled in the future and hasn’t run so would want to cancel it so it never runs.

As for a job that is already running but takes long time to finish one might need to manually check for is_cancel_reqested() and stop processing further. Long running process such as video encoding/decoding is a sample use case for this.

My app choose dynamically between sqlite and postgres. Is it possible to support AnyPool from sqlx instead of using only SqlitePool for SqliteQueue::with_pool(anypool)?

I would also like to store queue in struct but it currently requires specifying JobHandle?

pub struct AppState {
  queue: Arc<Queue>,
}

let queue = match anypool.any_kind() {
    AnyKind::Postgres => PostgresQueue::with_pool(anypool),
    AnyKind::Sqlite => SqliteQueue::with_pool(anypool),
    AnyKind::MySql => MySqlQueue::with_pool(anypool),
}

let appstate = AppState { queue };

For now it doesn't matter much since aide-de-camp only supports sqlite, but would like to make it work for generic cases where I can easily swap the queue.

Hi, thanks for making this library. It's been really great to use so far. I've been tinkering with adding support for graceful shutdowns using Tokio's cancellation tokens in order to allow jobs to react to shutdown requests and perform any cleanup tasks before the server shuts down.

The basic flow is that the user can request the server to shut down by supplying an arbitrary future that will cancel the server on completion just like Hyper's with_graceful_shutdown method. The cancellation token gets propagated from the runner to the router's listen method and then to the process method so every component can react to the shutdown request. I also added some configuration options for consumers to optionally supply a cancellation timeout that specifies how long to wait for a graceful shutdown before the shutdown is forcefully completed.

Additionally, I added the cancellation token to the processor trait's handle method so that each job can easily react to the shutdown request in a standardized way. Now the method looks like this:

 async fn handle(
        &self,
        jid: Xid,
        payload: Self::Payload,
        cancellation_token: CancellationToken,
    ) -> Result<(), Self::Error>;

However, this is obviously a breaking change to the public API. I think it would be ergonomic for each job to have easy access to the cancellation request, but I can understand if you want to keep the handler method as simple as possible and leave it up to the consumer to propagate the cancellation request through some other means.

Let me know if you'd be interested in a PR for this and I can clean up my proof of concept and submit it for review.

Some urgent task would need to be schedule earlier than existing one. Allowing us to pass priority as a number would allow us to enable this scenario.

Would be great if SurrealDB is supported. It would be best of both sqlite+postgres. It support running embedded as well as in distributed mode and has native support for event which could avoid polling.