Some problems with creating a scheduled task to run only once

My goal is to create a scheduled task to run only once on a specified date, on the first try, it seemed good until my schedule got repeated.

So, I read about repeats As the docs pointed, the default value for repeats is -1 which means always, so I set it to 0 as it means never so, my schedule never repeats and only run once.

Here is an example of what I did

schedule('app.tasks.auto_subscription_renew',
                     amount_cents, currency, instance.profile.id,name=schedule_name,repeats=0, schedule_type=Schedule.ONCE, next_run=end_date)

The problem is, when set to 0, the scheduler never run. Then I find this hint about Schedule.ONCE

So, I tried another value like -5, nothing changes, the same behaviour as -1

Also, what about the issue of multiple workers to catch the same task and run it twice? I had set it to 8 workers before but changed this to 1

Here is my conf, and for cache, I didn’t set up one, the default in-memory cache in Django is being used for sure.

Q_CLUSTER = {
    'name': '_tasks',
    'workers': 1,
    'daemonize_workers': False,
    'retry': 3600,
    'compress': True,
    'save_limit': 0,
    'orm': 'temp',
    'bulk': 20
}

[Koed00]

Ok I understand the problem now; one of the contributros added the option to have the queue on a different database, but it was never intended to run everything, including the admin and schedule stuff, on a separate db connection. There is another issue on this somehwere, but I can’t quite find it right now.

We would have to the option to run everything on a different db for your setup to completely work. Which I’m all for. A quick workaround could be to add the schedule object (and other objects) to a database router and let django know where to find them by default.

[mohmyo]

Thank you so much, I have a better understanding for this now, but I feel there are plenty of points that should be added to the documentation to make it more clear and stop confusion because I only followed it and got to the current situation.

Now, I will compare between running on the default for now and switch to a separate later when it’s complete, or do the workaround you mentioned, it depends on the scale I’m expecting, so I should reconsider this again.

Thanks again for your help and your effort to make this package great!