Inside Refactor: Don't Warn On Nil Shutdown

refactor: don't warn on nil Shutdown in longrun.Runner.Add

The quiet warning about nil Shutdown in longrun.Runner.Add reveals a subtle tension in how systems handle graceful exits. While developers expect a clean shutdown, the current pattern triggers a alert when the context is nil - typical in long-running processes that rely on context cancellation, like the worker script in schedule.go:38. This isn’t an error; it’s a design choice meant to avoid false failures during planned stops. Yet, silently ignoring a nil Shutdown can hide real risks - especially when no fallback function is provided.

Here is the deal: context cancellation is standard in modern Go, but treating nil Shutdown as a warning rather than a fatal flaw lets processes fade cleanly. But without a defined no-op fallback, teams might unknowingly lose signal during shutdown.

• Context cancellation is the norm in long-running Go services, but often misinterpreted as an error when nil appears.
• The longrun.Runner.Add pattern expects Shutdown to be nil in cancellation cases - this is expected behavior, not a bug.
• Without explicit no-op handling, silence risks masking incomplete cleanup, even if no data loss occurs.
• Adding a lightweight no-op function - like a no-op shutdown wrapper - can clarify intent and prevent blind spots.
• Pro tip: Log nil Shutdown only when paired with a no-op, not as a warning, to avoid noise.

The bottom line: embrace nil Shutdown as part of the pattern, but clarify intent with optional fallback. When designing long-run processes, ask: does silence protect or obscure?