Beat ignores all other periodic tasks between consecutive runs of a CrontabSchedule when its timezone column is NULL

[mvinoba]

Environment

component	version
django‑celery‑beat	2.7.0
Celery	5.5.1
Django	5.0.2
Python	3.11
Broker	Redis

CELERY_TIMEZONE = "America/Sao_Paulo"
CELERY_ENABLE_UTC = False
CELERY_BEAT_SCHEDULER = "django_celery_beat.schedulers:DatabaseScheduler"
DJANGO_CELERY_BEAT_TZ_AWARE = True

What happened in production

One CrontabSchedule row was configured (incorrectly) with minute="30", hour="6,9", timezone=NULL.

After the job ran at 06 h 30 (local), Celery Beat dispatched no other periodic task until it "fired again" at 09 h 30.

Disabling the task immediately restored normal scheduling and all other jobs resumed as expected. All other jobs have timezone="America/Sao_Paulo" .

Expected

Beat should execute the 06 h 30 / 09 h 30 job and continue processing the rest of the periodic‑task queue in between.

Actual

All other periodic tasks were skipped during that three‑hour window.

[auvipy]

can you reproduce it in the main branch?

[mvinoba]

can you reproduce it in the main branch?

Version 2.8.0 unfortunately didn’t resolve the issue.

[databyte]

Did you recently update the redis package to 6.0.0 or has it been stable at 5.x?

[mvinoba]

Did you recently update the redis package to 6.0.0 or has it been stable at 5.x?

We've been using redis==5.0.1. No changes recently.

[auvipy]

timezone column is NULL, is this a good practice?

[mvinoba]

timezone column is NULL, is this a good practice?

Definitely not, but the behavior is odd and undocumented. Do you happen to know what might be causing the issue?

[yanivtoledano]

Did you recently update the redis package to 6.0.0 or has it been stable at 5.x?

@databyte - we recently upgraded to redis 6.x from 5.x and have had intermittent issues with beat tasks no longer triggering ever since. Has something changed in redis that's affecting celery beat (given you're asking)?

[databyte]

@yanivtoledano Yes, I wasn't sure if this was related or not. I haven't posted a separate issue yet. We've locked redis back to 5.x for now. I haven't had time to track down where the issue might be with the redid 6.0 client.

I do know that what we witnessed was all the initial jobs would execute on startup and then everything would miss after that. But we're also dealing with the issue #875 so I'm waiting for that to stabilize first before trying to tackle a different celery issue.