You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
queue-runner and builder: fail fast on infrastructure errors
The queue-runner should not try to recover from a down database or
invalid store state — only builder failures should be totally
recoverable since builders are numerous and expected to come and go.
The builder should die if it cannot communicate with the queue-runner —
the queue-runner will notice and retry the step elsewhere.
Also there are `nix_utils::BaseStore` trait changes:
- `is_valid_path` now returns `Result<bool, Error>` instead of `bool`
- `query_path_info` now returns `Result<Option<...>, Error>` instead of
`Option<...>`
- `query_path_infos` now returns `Result<HashMap<...>, Error>` instead
of `HashMap<...>`
- `compute_closure_size` now returns `Result<u64, Error>` instead of
`u64`
Previously the trait implementations silently swallowed FFI errors as
"path not found" / empty / zero. This was the root cause of silent
failures: a daemon connection error looked like "path is present" to
callers, causing paths to be skipped from import and builds to fail with
cryptic errors.
The C++ `query_path_info` now checks `isValidPath` first and returns a
`found: false` sentinel instead of throwing `InvalidPath` — eliminating
brittle error-message string matching on the Rust side.
All callers updated to propagate errors with `?`.
**Note: Manual review of the queue runner error comments is not yet
complete!**
Queue-runner changes:
- `create_build` returns `Result`; an invalid drv path is a hard error
(indicates a GC rooting bug) rather than silently aborting the build
- `handle_previous_failure` and `handle_cached_build` errors propagate
(DB unreachable = stop processing)
- `process_new_builds` returns `Result` and propagates child build
creation errors
- Queue monitor loop propagates `get_queued_builds`,
`process_queue_change`, and `handle_jobset_change` errors instead of
logging and continuing
- Log directory creation at startup is fatal on failure
- mTLS misconfiguration uses `anyhow::ensure!`
- Non-fatal `tracing::error!` sites documented with comments
explaining why they are correct to log-and-continue
Builder changes:
- `filter_missing` returns `Result` — daemon connection failure is
a hard error, not "path is present"
- `handle_request` errors propagate (kills the builder — queue-runner
will retry)
- Ping message construction failure breaks the ping stream (builder
exits), with the error captured and returned from the gRPC function
- `submit_build_result` helper deduplicates the retry-then-report
pattern for `complete_build` calls
- Build task returns `Result<()>` instead of `()` — failure to submit
results after retries propagates rather than calling
`process::exit(1)`
- mTLS misconfiguration uses `anyhow::ensure!`
- Unreachable error paths in log stream (`utils.rs`) now panic with
explanatory comments
- `substitute_output` S3 replication uses async-block-as-try-block
pattern for clean early exit on daemon error
0 commit comments