fix: exit 0 on graceful SIGTERM/deadline shutdown

[bdchatham]

Summary

seiload exits non-zero on every graceful shutdown. Treat context.Canceled (and context.DeadlineExceeded for future-proofing) as the expected end-of-run signal at the top-level boundary of runLoadTest.

Root cause

Tracing the chain when Kubernetes SIGTERMs the container at activeDeadlineSeconds:

1. Signal handler in runLoadTest (main.go:347-352) catches SIGTERM cleanly and the main task closure passed to service.Run returns nil.
2. service.Run (utils/service/start.go:124-132) cancels its internal context once the main task finishes.
3. Background tasks see ctx.Done() and return ctx.Err() (= context.Canceled):
   • sender/dispatcher.go:106
   • stats/logger.go:253
   • stats/block_collector.go:87
4. SpawnBgNamed (utils/service/start.go:101-113) wraps with fmt.Errorf("%s: %w", name, err) — preserves errors.Is traversal.
5. errgroup returns the first error → runLoadTest returns it (main.go:365) → rootCmd.Run calls log.Fatal(err) (main.go:49) → exit 1.

Net effect: every successful nightly run exits 1, the K8s Job goes to Failed, and kube_job_failed=1 fires KubeJobFailed alerts on the harbor cluster (8 distinct run IDs in the last 14d).

Fix

log.Printf("👋 Shutdown complete")
if errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded) {
    err = nil
}
return err

Conventional Go pattern at the process boundary (parallels http.ErrServerClosed). The signal handler at main.go:351-352 already declares "SIGTERM is graceful" by returning nil; this honors that intent. DeadlineExceeded is included defensively — the internal ctx in service.Run is WithCancel today so it can't appear, but if anyone wraps the parent in WithTimeout later we'd regress.

Why at the boundary, not at task sites

Considered pushing return nil into each background task, but return ctx.Err() at task sites is honest signal: if a sibling task fails for a real reason (sender error, RPC down) and that propagates ctx-cancellation, you want each background task to surface that fact, not silently swallow it. The boundary check is the right level — a single point where the process owner decides "this counts as success."

Test plan

• go build . passes
• Next nightly run on harbor: K8s Job should reach condition=Complete, kube_job_failed stays at 0, and KubeJobFailed alert clears for new runs

Production impact

Fixes the upstream cause of KubeJobFailed warnings on nightly/seiload-* Jobs (harbor cluster, nightly namespace). Companion PR in sei-protocol/platform adds (a) EKS auth refresh in the workflow's teardown step and (b) a defense-in-depth GC CronJob, which together address resource leaks discovered while diagnosing this exit-code issue.

🤖 Generated with Claude Code