feat: make per-job timeout 0 mean "no timeout" instead of inherit
A per-job timeout now has three distinct states: unset inherits the global default, an explicit 0 means no timeout and does not inherit, and a positive value is the per-job limit. Job.TimeoutSeconds became *int so unset and 0 stay distinguishable in jobs.json. Also fixes the global default, which could not persist a 0. loadOrCreateConfig normalized DefaultTimeoutSeconds <= 0 back to 30 on every read of an existing gosentry.json, so "no timeout" only held until the next restart. The field is now written unconditionally (no omitempty) and read back as-is. Existing jobs and configs are unaffected: a job with no timeout_seconds still inherits, and a saved global default of 30 stays 30. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
+15
-4
@@ -131,10 +131,21 @@ in flight increments `JobRuntime.PendingRuns`. When the current run finishes,
|
||||
|
||||
### Per-job command timeout
|
||||
|
||||
`domain.Job` carries a `TimeoutSeconds` field (`json:"timeout_seconds,omitempty"`),
|
||||
following the same inherit pattern as the overlap policy. `0` means inherit the
|
||||
global `Config.DefaultTimeoutSeconds` (default **0**, i.e. no timeout); a
|
||||
positive value overrides it for that job alone. `app.Service.effectiveTimeout`
|
||||
`domain.Job` carries a `TimeoutSeconds *int` field
|
||||
(`json:"timeout_seconds,omitempty"`), following the same inherit pattern as the
|
||||
overlap policy. It is a **pointer** because the setting has three states that
|
||||
must stay distinguishable on disk:
|
||||
|
||||
| `Job.TimeoutSeconds` | jobs.json | Meaning |
|
||||
| --- | --- | --- |
|
||||
| `nil` | field absent | inherit `Config.DefaultTimeoutSeconds` |
|
||||
| `0` | `"timeout_seconds": 0` | no timeout, does **not** inherit |
|
||||
| `> 0` | `"timeout_seconds": 45` | per-job limit in seconds |
|
||||
|
||||
The global `Config.DefaultTimeoutSeconds` (default **0**, i.e. no timeout) is
|
||||
written unconditionally — no `omitempty` — for the same reason: `0` there is a
|
||||
deliberate choice, not a missing value, and `storage.loadOrCreateConfig` must not
|
||||
normalize it away. `app.Service.effectiveTimeout`
|
||||
resolves the effective duration under `mu` and `startRunLocked` snapshots it into
|
||||
`runEnv.timeout`. `runner.RunJob(ctx, job, trigger, logsDir, timeout)` takes the
|
||||
resolved duration as an argument, so the runner stays ignorant of the global
|
||||
|
||||
Reference in New Issue
Block a user