fix(resolver): dedupe override.yml; apply gpu_backends filter to user-extensions#1029
Conversation
…-extensions Two resolver-layer defects fixed together because they cluster in the same call chain. 1. installers/lib/compose-select.sh double-appended docker-compose.override.yml to COMPOSE_FLAGS. scripts/resolve- compose-stack.sh already appends it once when its env output is consumed by compose-select.sh's load_env_from_output. Removing the redundant bash-level append leaves the resolver as the single source of truth. 2. scripts/resolve-compose-stack.sh included every data/user-extensions/<id>/compose.yaml unconditionally, bypassing the gpu_backends compatibility check that the built-in extension loop already performs. An NVIDIA-only user extension installed on AMD/Apple would be merged into the stack and fail at container start. This adds the same manifest read + schema_version + gpu_backends filter the built-in loop uses, verbatim, including "all"/"none" sentinels and the narrow-dispatch error handling gated by skip_broken.
|
Audit follow-up: not merge-ready as-is. The resolver dedupe and manifest-declared GPU filtering direction is good, but this branch silently drops legacy/custom user extensions that have |
|
Closing as superseded by #1051. The maintainer audit on this PR (2026-04-28) flagged that the manifest-only filter silently drops legacy/custom user extensions whose
The maintainer's own audit on #1051 said it was "better than #1029". Closing #1029 to remove the duplicate from the queue. |
What
Two resolver fixes bundled:
docker-compose.override.ymltwice toCOMPOSE_FLAGS.gpu_backendsfilter to user-installed extensions that built-in extensions already receive.Why
Defect 1:
installers/lib/compose-select.shcalled the resolver (which appendsdocker-compose.override.ymlinternally) and then appended it again at the bash layer. Docker merges the file twice — idempotent for scalars but a foot-gun for anchors /extends:/ list-merge semantics.Defect 2:
scripts/resolve-compose-stack.shread the manifest and filtered bygpu_backendsfor built-in extensions but included everydata/user-extensions/*/compose.yamlunconditionally. A user-library extension declaringgpu_backends: [nvidia]would be merged on AMD/Apple and fail at container start — or worse, block anydepends_onchain.How
if [[ -f ... override.yml ]]block afterload_env_from_output..yaml->.yml->.json), sameschema_version == "dream.services.v1"gate, samegpu_backendsdefault["amd","nvidia"], same"all"/"none"sentinels, same narrow yaml/json/structure exception dispatch honouringskip_broken.The intentional scope limit: user-extension loop still hardcodes
compose.yamland does not applycompose.local.yaml/compose.multigpu.yamloverlays — those gaps pre-dated this PR and are left for a separate follow-up to keep blast radius small.Testing
bash -n,shellcheck(zero net-new warnings),python3 -m py_compileon the extracted heredoc — all pass.make lint— passes.tests/test-tier-map.sh— 82/0.override.yml, new code emits 1x.gpu_backends: [nvidia]user-ext filtered out on AMD, included on NVIDIA.gpu_backends: [all]included on every backend.Review
Critique Guardian APPROVED (no required changes).
Platform Impact
pathlib; no BSD/GNU divergence. compose-select.sh change is Linux-installer-only (matches file's scope).