Effects that share a `lock` and are ordered with `after` deadlock unless their names sort in dependency order
Maintainers usually reply within 1 day
@Padraic-O-Mhuiris is already working on this.
Since Nov 12, 2026.
- #293 by @Padraic-O-Mhuiris — open
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start with nixbot/nixbot/queries/work_queue.sql, especially the ordering in EnqueueEffectItems and the shared deduplication behavior in ClaimNextWorkItem. Trace how dependency readiness interacts with FIFO claiming for effects that share a lock. Done means the dependent effect runs after its prerequisite, and later effects on that lock are no longer blocked.
Written by the indexing model from the issue text.
Description
At 171a8c7 (current main).
Two push effects share a lock, and one runs after the other:
herculesCI = { ... }: {
onPush.default.outputs.effects = {
migrate = mkEffect { lock = "env"; effectScript = "echo migrate"; };
apply = mkEffect {
lock = "env";
after = [ [ "default" "migrate" ] ];
effectScript = "echo apply";
};
};
};
Expected: after a green build, migrate runs, then apply.
Actual: both stay pending indefinitely, and so does every later effect on the env lock, in this build and the ones after it. Renaming the effects so the dependency sorts first (a-migrate,
b-apply) works around it.
Why:
EnqueueEffectItemsqueues a build's effect itemsORDER BY u.name(work_queue.sql#L26), soapplyis
queued beforemigrate.ClaimNextWorkItem(L31-L80) serves items that share adedup_key, here the lock, strictly first
in, first out, somigratecan't be claimed while the olderapplyis pending.applyis held back until its dependency settles, so neither ever runs.
- Dominant language
- Python
- Stars
- 118
- Forks
- 22
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 13
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Mic92/nixbot
-
A rebuild posts "not part of this build" success to the commit's failed `nix-build` gate and effectsPossibly taken @Padraic-O-Mhuiris claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Restarted builds lose credentials when re-evaluating private flake inputsPossibly taken @Ramblurr claimed this 13 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
A per-attribute restart leaves the attribute's status pendingPossibly taken @Padraic-O-Mhuiris claimed this today. Open
Difficulty 3/5 1-2 days Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 51/100
Maintainers usually reply within 1 day
Similar issues
-
component/fhir type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
OpenConceptLab/ocl_issues#3026 ·
-
ODS datetime imports reject fractional seconds and exports drop themPossibly taken @IlyaKhalafi claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
TauricResearch/TradingAgents#1693 ·
Maintainers usually reply within 2 days
-
requests support
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
UKGovernmentBEIS/inspect_ai#6537 ·
Maintainers usually reply within 1 day