Worker configuration lint

Some worker defaults lose work, and they do it quietly. A task acknowledged before it runs is gone if the process dies mid-task, and nothing in the queue, the logs, or the dashboard says so: the task simply never completed and no one is told. The lint reads the configuration each worker already reports on its heartbeat and names the settings with that shape.

It is advisory and read-only. Nothing here changes a worker, and a finding is a prompt to look rather than a fault. Some of these settings are the right choice for some workloads.

Where to find it

The Workers page for a project shows a Configuration lint panel above the worker table. The same result is available from the API:

curl -s https://z4j.example.com/api/v1/projects/<slug>/workers/lint \
  -H "Authorization: Bearer $Z4J_API_KEY"

Reading it costs one query and collects nothing new, because the configuration was already on the heartbeat.

What it checks

Rule	Setting	Severity	What it means
celery.pickle-accepted	accept_content	high	Workers deserialize pickle, so anyone who can publish to the broker can execute code in the worker
celery.acks-late-off	task_acks_late	medium	Tasks are acknowledged before they run, so a worker that dies mid-task loses the task silently
celery.lost-task-not-requeued	task_reject_on_worker_lost	medium	Late acknowledgement is on, but a lost worker's task is not redelivered, which reintroduces the loss late acknowledgement was meant to prevent
celery.prefetch-unbounded	worker_prefetch_multiplier	medium	Each worker reserves the queue without limit, so one worker can hold work the others sit idle waiting for
celery.prefetch-hoarding	worker_prefetch_multiplier	low	Each worker reserves several tasks per slot, which is the same problem in a milder form
celery.no-time-limit	task_time_limit	medium	Tasks can run forever, so one wedged task holds its slot indefinitely

What it does not check

Two numbers are reported, and the difference between them matters.

workers_evaluated counts workers that were actually judged. workers_not_evaluated counts workers that were not, either because their engine has no rules yet or because they reported no configuration. That is not the same as a clean result, and the panel says so rather than folding the two together.

Rules currently exist for Celery. A worker on another engine is counted as not evaluated and returns no findings, which is why an all-clear on a fleet with no Celery workers means the check had nothing to say rather than that the fleet is configured well.

Acting on a finding

Every finding carries a remedy naming the setting to change. Change it in your application's configuration and restart the worker; the next heartbeat reports the new value and the finding clears on its own. Nothing needs to be acknowledged or dismissed in z4j.

If a flagged setting is deliberate for your workload, leave it. The lint has no suppression mechanism on purpose: a list of permanently ignored findings tends to become a list nobody reads.