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
[nar info cache] Only fillNarInfoCache in perf-sensitive code path (#1468)
## Summary
In this PR, we loosen the conditions under which
`devpkg.Package.IsInBinaryCache` can be called. Internally, it checks an
in-memory map for the status of the package in the binary cache.
Previously, it was _required_ that callers pre-compute this status by
invoking `FillNarInfoInCache`. The motivation then was to ensure that we
avoid a synchronous http request if `IsInBinaryCache` is called within a
loop.
However, this condition and the fact that golang lacks async-await
support resulted in a loosely coupled load-and-check-later design
whereby calls to `FillNarInfoInCache` would be sprinkled in various
parts of the codebase and then `IsInBinaryCache` checked in other parts.
This loose-coupling made it hard to reason about _why_ any particular
FillNarInfoInCache was present.
The straw that broke the proverbial camel's back was the issue that
#1463 was seeking to fix.
In this PR, we add a fallback http request inside `IsInBinaryCache` and
remove all but one of the `FillNarInfoInCache` calls. Reason:
1. The remaining callsite is in the hot codepath of calculating
`shellenv`.
2. The other callsites were in the codepaths of adding or installing
packages. This is necessarily a slow operation, and so a small bit of
synchrony is acceptable.
NOTE: this PR also re-enables Remove Nixpkgs feature flag.
## How was it tested?
- did some adhoc testing of opening a shell in an example project
- added testscript unit-test for adding packages that are not in the
Devbox Search Index. re: #1463's scenario
- prior testscript unit-tests and project-tests should pass.
0 commit comments