pub trait SyncJob<S = ()>: Clone {
    fn run(self, state: S) -> Result<(), Error>;

    fn queue(&self) -> Option<&str> { ... }
    fn max_retries(&self) -> Option<MaxRetries> { ... }
    fn backoff_strategy(&self) -> Option<Backoff> { ... }
    fn to_job(self) -> SyncJobWrapper<Self, S> { ... }
}
Expand description

The SyncJob trait defines parameters pertaining to a synchronous instance of background job

This trait should be implemented sparingly, but is provided so that synchronous tasks may be executed. If you have the ability to implement the Job trait directly, you should.

Example

use background_jobs_server::SyncJob;
use failure::Error;
use log::info;
use serde_derive::{Deserialize, Serialize};

#[derive(Clone, Deserialize, Serialize)]
struct MyJob {
    count: i32,
}

impl SyncJob for MyJob {
    fn run(self, _state: ()) -> Result<(), Error> {
        info!("Processing {}", self.count);

        // Perform some synchronous operation, like a DB action with r2d2 and diesel

        Ok(())
    }
}

fn main() {
    let sync_job = MyJob { count: 0 };
    let job = sync_job.to_job();
}

Required Methods§

Users of this library must define what it means to run a job.

This should contain all the logic needed to complete a job. If that means queuing more jobs, sending an email, shelling out (don’t shell out), or doing otherwise lengthy processes, that logic should all be called from inside this method.

The state passed into this job is initialized at the start of the application. The state argument could be useful for containing a hook into something like r2d2, or the address of an actor in an actix-based system.

Provided Methods§

If this job should not use the default queue for its processor, this can be overridden in user-code.

Jobs will only be processed by processors that are registered, and if a queue is supplied here that is not associated with a valid processor for this job, it will never be processed.

If this job should not use the default maximum retry count for its processor, this can be overridden in user-code.

If this job should not use the default backoff strategy for its processor, this can be overridden in user-code.

Wrap this type in a SyncJobWrapper so it implements Job

Implementors§