fix(devpkg): treat binary cache narinfo network errors as a cache miss

[mikeland73]

Summary

Before running a script or shell, devbox HEADs https://cache.nixos.org/<hash>.narinfo for each package with a 5s timeout to decide whether it can fetchClosure instead of building. A timeout, DNS failure, or connection reset from that check propagated up and failed the whole command (seen as a flaky script.test failure in CI on #2971). Since the check is only an optimization, transport errors now return "not in cache" (with a debug log) so the caller falls back to letting Nix build/substitute the package — a slow cache makes the command slower, not fail. Non-2xx responses were already treated this way; the result is still memoized per hash so all callers in one command agree.

How was it tested?

Added narinfo_cache_test.go covering 200 → hit, 404 → miss, a server that hangs past the timeout → miss with no error, and a refused connection → miss with no error. go build ./..., go vet, and go test ./internal/devpkg/ ./internal/shellgen/ pass.

Community Contribution License

All community contributions in this pull request are licensed to the project
maintainers under the terms of the
Apache 2 License.

By creating this pull request, I represent that I have the right to license the
contributions to the project maintainers under the Apache 2 License as stated in
the
Community Contribution License.

🤖 Generated with Claude Code

[mikeland73]

@claude ptal

[claude]

Claude finished @mikeland73's task in 1m 25s —— View job

---

Claude's Review

• Gather context (PR diff, files, CLAUDE.md)
• Review internal/devpkg/narinfo_cache.go changes
• Review internal/devpkg/narinfo_cache_test.go
• Post review feedback

This is a clean, well-scoped fix. A few notes:

internal/devpkg/narinfo_cache.go

• The core change (internal/devpkg/narinfo_cache.go:234-236) is correct: http.DefaultClient.Do errors (timeout, DNS failure, connection reset) now return (false, nil) with a debug log instead of propagating, matching how non-2xx responses were already handled. This is consistent with the doc comment added above fetchNarInfoStatusFromHTTP and with the existing memoization behavior in sync.OnceValues (previously a transient network error would have been cached as an error for the whole command's lifetime, which was arguably worse — now it's cached as a miss, which is the stated intent).
• Extracting the timeout into the package var narInfoHTTPTimeout for test injection is a reasonable, minimal way to make the timeout path testable without adding a config knob.
• slog.Debug usage here is consistent with the rest of the codebase, which routes through internal/debug's configured default handler (internal/debug/debug.go:35), so this will show up under the existing debug/verbose flag.
• Errors from http.NewRequestWithContext are still propagated (not swallowed) — correct, since that's a programming error, not a transport failure.

internal/devpkg/narinfo_cache_test.go

• Good coverage: hit (200), miss (404), timeout (hangs past a shortened 50ms timeout), and connection-refused (server closed before request). The timeout/refused cases correctly assert err == nil alongside inCache == false, which is the actual behavior being fixed.
• The timeout test mutates the package-level narInfoHTTPTimeout and restores it via defer, and each subtest uses a distinct httptest server (distinct port), so there's no collision risk with the shared narInfoStatusFnCache sync.Map across subtests.
• Minor/non-blocking: release/srv.Close() defer ordering is correct (handler released before server closes), avoiding a stuck goroutine.

No bugs found. I wasn't able to run go build/go vet/go test myself in this sandbox (those commands require approval I don't have here), but the logic checks out against a manual read, and the PR description states these were run locally with passing results.