Skip to content

Checking broken with only some outputs #13293

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
2 tasks
Ericson2314 opened this issue May 29, 2025 · 1 comment · May be fixed by #13294
Open
2 tasks

Checking broken with only some outputs #13293

Ericson2314 opened this issue May 29, 2025 · 1 comment · May be fixed by #13294
Labels

Comments

@Ericson2314
Copy link
Member

Ericson2314 commented May 29, 2025

Describe the bug

Since DerivationBuildingGoal was split out (3b617e4), checking is broken because of an DerivationBuildingGoal::assertPathValidity call at

return miscMethods->assertPathValidity();

The issue is that DerivationBuildingGoal doesn't know what outputs are wanted any more. This was intentional --- when we are building rather than substituting, we know we are going to produce all outputs. However this assertPathValidity was happening before the build, and was intended to check that the outputs we want to repair are all there.

Steps To Reproduce

  1. Substitute some but not all outputs of a derivation.
  2. Repair that derivation
  3. Get an error message about missing unexpected invalid outputs, not because the outputs we have are broken, but because the outputs that we don't have, and don't care about not having.

Expected behavior

It should be fine to only repair some outputs, just like before

Metadata

Bisected to 3b617e4

Additional context

I would like to not solve this issue by reintroducing wantedOutputs to DerivationBuildingGoal. Can we instead solve this problem a different way?

Possible solutions:

  1. Elide the check: if we got this far, at least some of the outputs should be valid, right?
  2. Skip the early return: We did a build, so we have all the outputs now, we might as well register them in case we were missing some before
  3. Just do the earlier return, but then in DerivationGoal after we return do the check. Then we're back to knowing what output we want.

Checklist


Add 👍 to issues you find important.

CC @xokdvium

Ericson2314 added a commit to obsidiansystems/nix that referenced this issue May 29, 2025
We move the `assertPathValidity` to where we know what the wanted
outputs are.
@Ericson2314 Ericson2314 linked a pull request May 29, 2025 that will close this issue
@Ericson2314
Copy link
Member Author

#13294 This implements solution (3) above.

xokdvium pushed a commit to xokdvium/nix that referenced this issue May 29, 2025
We move the `assertPathValidity` to where we know what the wanted
outputs are.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant