Voiceware: Background Work · deep-dive
The celery-low Fix Was a Configuration-Contract Failure
Connecting missing type, missing service port, and command fixes into one root lesson.
Symptom
I fixed celery-low in three small steps: the deployment command and values, the missing service.port, and then the missing celery.type.
The symptom pointed at the wrong layer. The failures were not one mysterious Kubernetes bug; they were multiple gaps between the chart template and the values contract.
My first rule: identify the stage of failure
producer -> queue/broker -> worker class -> task execution -> side effect
What I checked
I checked queue depth, oldest-job age, task execution time, worker availability, retry/error rate before changing anything.
Where the problem actually was
What this came down to was this: The failures were not one mysterious Kubernetes bug; they were multiple gaps between the chart template and the values contract. From that I kept one rule: When a workload is special, give it an explicit schema and test the rendered command and manifest together.
Prevention checklist
- Test process commands exactly as rendered in the pod spec.
- Measure queue wait separately from execution time.
- Confirm workers consume the intended queue.
- Scale from workload pressure, not CPU alone.
- Keep scheduler semantics separate from worker semantics.