jetify-com/devbox#2042 introduced a bug where adding non-cached packages would fail to add them to the flake on the first attempt. (it would succeed on subsequent attempts after the package is already in the store).
The root cause is that fetchNarInfoStatus gets called twice per package (even though we cache it and we're not supposed to call it twice). The first call returns false because the package is not cached. The second call returns true because the package is already in store. This discrepancy essentially causes the package not to appear on the flake at all. When updating state again, the package is already in the nix store so both fetchNarInfoStatus calls return true.
I think reverting this is best immediate course of action. In follow up we should fix fetchNarInfoStatus so it only gets called once (it will improve performance and is more correct).
Later on we can think of better way to do jetify-com/devbox#2042. The current implementation is a bit fragile and not 100% consistent with the initial intention of the function, so I'm concerned it can lead to more bugs in the future.
Reverts jetify-com/devbox#2042
jetify-com/devbox#2042 introduced a bug where adding non-cached packages would fail to add them to the flake on the first attempt. (it would succeed on subsequent attempts after the package is already in the store).
The root cause is that
fetchNarInfoStatusgets called twice per package (even though we cache it and we're not supposed to call it twice). The first call returnsfalsebecause the package is not cached. The second call returnstruebecause the package is already in store. This discrepancy essentially causes the package not to appear on the flake at all. When updating state again, the package is already in the nix store so bothfetchNarInfoStatuscalls return true.I think reverting this is best immediate course of action. In follow up we should fix
fetchNarInfoStatusso it only gets called once (it will improve performance and is more correct).Later on we can think of better way to do jetify-com/devbox#2042. The current implementation is a bit fragile and not 100% consistent with the initial intention of the function, so I'm concerned it can lead to more bugs in the future.