When a schedule's queue is not declared, the message names a queue the user may never have typed:
queue 'reports' is not declared.
validate_declared_queue resolves the effective queue — the explicit override if given, else the task's own queue_name — then reports whichever it landed on. In the admin create form queue is not a field (it is resolved from the task), so the error is re-homed onto the form as a non-field error. The result is a form with no queue input, failing over a queue name that came from a decorator the message never mentions, with no statement of what to do about it.
This is the common case, not an edge one: any task whose queue_name falls outside a narrowed QUEUES hits it — see tests/pg_cron/test_admin/test_scheduledtask.py:211.
Ship
Make the message carry provenance and a resolution, distinguishing the two paths that reach it:
- explicit override (
queue given on the schedule) — the user chose it; the current wording is fine
- derived from the task — say so, and name the fix: declare the queue in
OPTIONS["QUEUES"], or set an override
Both callers benefit: ScheduledTask.clean (via validate_queue_against_backend) and the absurd.E007 schedule check at django_absurd/checks.py:323. Keep this project's msg/hint split on the check path — the problem in msg, the resolution in hint.
Source: django_absurd/pg_cron/validators.py:52.
Note for whoever picks it up
Several tests assert the current text and will need updating — tests/pg_cron/test_pg_cron_checks.py (including queue '' is not declared for an empty override), test_scheduler_app_checks.py:83, test_admin/test_scheduledtask.py:233 and :258, validators/test_declared_queue.py:20. That empty-override case is worth its own wording: queue '' is not declared reads as a bug in the message rather than a statement about the config.
Supersedes the original scope of this issue (a check for a backend declaring no queues), which needed a deliberate QUEUES: [] plus the pg_cron app — too narrow to warrant a check ID, while the misleading message affects every undeclared-queue case.
When a schedule's queue is not declared, the message names a queue the user may never have typed:
validate_declared_queueresolves the effective queue — the explicit override if given, else the task's ownqueue_name— then reports whichever it landed on. In the admin create formqueueis not a field (it is resolved from the task), so the error is re-homed onto the form as a non-field error. The result is a form with no queue input, failing over a queue name that came from a decorator the message never mentions, with no statement of what to do about it.This is the common case, not an edge one: any task whose
queue_namefalls outside a narrowedQUEUEShits it — seetests/pg_cron/test_admin/test_scheduledtask.py:211.Ship
Make the message carry provenance and a resolution, distinguishing the two paths that reach it:
queuegiven on the schedule) — the user chose it; the current wording is fineOPTIONS["QUEUES"], or set an overrideBoth callers benefit:
ScheduledTask.clean(viavalidate_queue_against_backend) and theabsurd.E007schedule check atdjango_absurd/checks.py:323. Keep this project's msg/hint split on the check path — the problem inmsg, the resolution inhint.Source:
django_absurd/pg_cron/validators.py:52.Note for whoever picks it up
Several tests assert the current text and will need updating —
tests/pg_cron/test_pg_cron_checks.py(includingqueue '' is not declaredfor an empty override),test_scheduler_app_checks.py:83,test_admin/test_scheduledtask.py:233and:258,validators/test_declared_queue.py:20. That empty-override case is worth its own wording:queue '' is not declaredreads as a bug in the message rather than a statement about the config.Supersedes the original scope of this issue (a check for a backend declaring no queues), which needed a deliberate
QUEUES: []plus the pg_cron app — too narrow to warrant a check ID, while the misleading message affects every undeclared-queue case.