A task times out since a separate runner executes the code. The variable must go on the right container, and a manual run differs from the worker.
A background task times out every time. It used to work. An architecture change moved the execution, and the config stayed in the wrong place.
Execution moved to a separate runner
Before, the application executed its own tasks in its own process. Now the code goes to a dedicated runner: a separate worker, in its own container, consuming a queue and running the work.
That is where the timeout comes from. The worker does not have the same configuration as the web application. The variable that points to the slow resource, or sets the time limit, is set on the web container but missing from the worker container.
Set the variable on the right container
The variable must go on the container that actually runs the task, the worker, not the one that queues it. That is the common mistake after this kind of shift: the config follows the old execution model.
To confirm, compare a manual run with a run by the worker. Launching the task by hand from the web container can succeed, because it runs where the variable exists. The same task via the worker fails. The gap points to the container to fix.
The principle: config follows execution. When execution moves to a separate runner, its variables must move with it.