worker remote (PYTHON): single --timeout flag used as both poll timeout (ms) and exec timeout (s)

[mp-orkes]

Summary

conductor worker remote --type <task> with a PYTHON worker uses a single --timeout flag as two different timeouts, in two different units. The same integer becomes a millisecond poll timeout and a second-denominated worker execution timeout.

Details

In executePythonWorkerFromFile (cmd/worker.go), the flag is read once:

execTimeout, _ := cmd.Flags().GetInt32("timeout")   // cmd/worker.go:1136 — default 100

Used as the server-side long-poll timeout, in milliseconds:

if execTimeout > 0 {
    opts.Timeout = optional.NewInt32(execTimeout)   // cmd/worker.go:1170
}

Then passed as the worker execution timeout, which is interpreted in seconds:

executeExternalWorker(t, pythonCmd, []string{workerFile}, workerId, domain, execTimeout, false, taskClient)  // :1190

// executeExternalWorker, cmd/worker.go:551
if execTimeout > 0 {
    ctx, cancel = context.WithTimeout(ctx, time.Duration(execTimeout)*time.Second)
}

So the default --timeout 100 means a 100 ms poll timeout and a 100 s exec timeout. Raising the poll timeout silently raises the exec timeout by a factor of 1000, and there is no way to set one without changing the other.

The variable is also named execTimeout while being used as the poll timeout, which is likely how this crept in.

Scope

• Affects worker remote with language: PYTHON only.
• executeJsWorkerFromFile reads the same flag but uses it for polling only (cmd/worker.go:1002, :1025) — correct, though it inherits the naming confusion.
• worker stdio correctly separates --poll-timeout (ms) and --exec-timeout (s).

Suggested fix

Split the flags on worker remote to match worker stdio: --poll-timeout (ms) and --exec-timeout (s), and rename the local variable to match its use. Aligning the flag names across all worker subcommands is tracked separately in the convergence issue.

[mp-orkes]

Fixed as part of the worker convergence in #94, rather than as a standalone patch.

The convergence rewrites all four cmd/worker.go poll loops, so a separate minimal fix on executePythonWorkerFromFile would have been deleted by the same PR within a commit or two. #94 instead gives every worker subcommand the same two flags:

• --poll-timeout — server-side long-poll wait, milliseconds
• --exec-timeout — per-task execution budget, seconds
• --timeout — hidden deprecated alias for --poll-timeout, so existing invocations keep working (with a deprecation warning)

One detail worth flagging for whoever reviews #94: --exec-timeout defaults to 100s on worker remote, not 0. The old --timeout default of 100 reached executeExternalWorker as a 100-second kill timer, so defaulting to 0 (worker stdio's default, meaning no timeout) would have let a hanging remote Python worker run forever where it is bounded today.

Closing this via #94's Closes #91.