Skip to content

queue-runner: fix dynamic derivation scheduling and resolution - #1836

Open
amaanq wants to merge 3 commits into
NixOS:masterfrom
obsidiansystems:dyn-drv-queue-fixes
Open

queue-runner: fix dynamic derivation scheduling and resolution#1836
amaanq wants to merge 3 commits into
NixOS:masterfrom
obsidiansystems:dyn-drv-queue-fixes

Conversation

@amaanq

@amaanq amaanq commented Jul 23, 2026

Copy link
Copy Markdown
Member

When trying to run nix-ninja jobs with dynamic derivation through the queue runner, I hit three bugs in the two-phase CA dance. Regular CA builds only ever produce depth-1 chains, so none of these paths had really been exercised before it seems.

  • When a step resolves to a different drv path, the rdep migration used make_rdep, which records an empty OutputNameChain. As such, dynamic rdeps lost their relation, so pop_dynamic_rdeps found nothing when the resolved step finished and the generated derivation was never scheduled.
  • flatten_chain pushed the outermost output name onto the pop end of the chain, so an input like drv^out^hello resolved outermost-first and asked the outer derivation for the inner one's output.
  • A step whose resolved drv was already built errored with ResolvedStepCreationFailed and retried forever instead of finishing the build as cached. This is the early cutoff case the included test located at early-cutoff-sequential.t covers.

With these three bugs fixed, nix-ninja's example jobs build green end to end for me locally. The outer derivation runs nix-ninja inside the sandbox, the generated derivations get scheduled as real steps, and dependents resolve through the two-level chain!

@amaanq
amaanq force-pushed the dyn-drv-queue-fixes branch from c295496 to 8a60790 Compare July 23, 2026 18:09
@nixos-discourse

Copy link
Copy Markdown

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/dynamic-derivations-next-steps/79409/1

amaanq added 3 commits August 20, 2026 18:27
…teps

When a step resolves to a different drv path, its rdeps get migrated to
the resolved step with `make_rdep`, which records an empty
`OutputNameChain`. Dynamic rdeps lose their relation that way, so
`pop_dynamic_rdeps` finds nothing when the resolved step finishes and
the generated derivation never gets scheduled; anything depending on it
fails resolution forever.
`flatten_chain` pushed the outermost output name onto the end of the
chain, which is where `pop` reads from, so a depth-2 input like
`drv^out^hello` resolved outermost-first and asked the outer derivation
for the inner one's output. The outermost name now goes at the front,
matching the stack order `OutputNameChain` documents. I've also added a
debug trace for each resolution hop.
@amaanq
amaanq force-pushed the dyn-drv-queue-fixes branch from 8a60790 to 4cfe787 Compare August 20, 2026 22:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants