Not familiar with gearman or that module but from skimming the docs and code my take is that's a timeout for hearing a response back from asking gearman to start something as opposed to a timeout on the work you’re asking it to do. Terrrible analogy follows which may not be even relevant; but my impression is that it's kind of like the difference between expecting your waiter to take your order promptly (the command timeout) and how long it takes the kitchen to actually make the order once the waiter delivers it (a timeout on the job itself).

the documentation is really poor.. For the little I understood this command_timeout is an internal timeout for gearman protocol, like assigning task to worker, get resutls etc. If this is true is poorly described.

this github issue shows command_timeout was also undocumented up to 2018.

Also gearman.org documentation is not so explicit.

But using the source (Luke!) you can see $self->client()->{command_timeout} used as argument of the internal call to _wait_for_packet which then call Gearman::Util::read_res_packet which smell to me of internal protocol, not the meat of a job passed by your client.

There is a DEBUG flag you can set somwhere (tired by poor documentation, sorry), or probably a --verbose option. See other ENV vars that can be used to have more fun experimenting with your command_timeout option.

..then please submit a PR to the documentation :)

L*