mix/gosentry
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: make global default timeout 0 (infinite) instead of required 30s

Browse Source 
DefaultTimeoutSeconds now means "no timeout" when 0/empty, and that is
the new default, rather than an invalid config forcing a positive
value. runner.RunJob avoids context.WithTimeout with a zero duration
(which would expire immediately) and instead runs on a plain
cancelable context when no timeout is configured. Per-job
TimeoutSeconds inherit semantics are unchanged.
This commit is contained in:
mixeme
2026-07-26 13:57:03 +03:00
parent 3992b40eda
commit 33a246cd13
14 changed files with 75 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ARCHITECTURE.md
+10 -8
View File
@@ -133,14 +133,16 @@ in flight increments `JobRuntime.PendingRuns`. When the current run finishes,
`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 **30**); a positive value overrides
it for that job alone. `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 config: it applies the
timeout via `context.WithTimeout` and reports `Timed out after <timeout>` on
expiry. `StartOnly` jobs run on the untimed context and so measure launch latency
only, unaffected by the run timeout.
global `Config.DefaultTimeoutSeconds` (default **0**, i.e. no timeout); a
positive value overrides it for that job alone. `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
config: a positive duration applies the timeout via `context.WithTimeout` and
reports `Timed out after <timeout>` on expiry; a non-positive duration runs
without a deadline, bounded only by `ctx` (app shutdown). `StartOnly` jobs run on
the untimed context and so measure launch latency only, unaffected by the run
timeout.
### Run-time statistics