Fix: nextflow inspect not resolving config-based container overrides#6736
Merged
bentsherman merged 2 commits intonextflow-io:masterfrom Jan 20, 2026
Merged
Conversation
…extflow-io#6734) The `nextflow inspect` command was returning containers defined in process source files instead of the overridden values from profile configuration files (e.g., withName selectors). Root cause: In ProcessDef.createTaskProcessor(), the condition `if( !processConfig )` was meant to call initialize() if config wasn't set, but processConfig is always non-empty (initialized with DEFAULT_CONFIG values in the constructor), so initialize() was never called through this code path. The initialize() method is responsible for applying config file settings (withName/withLabel selectors) to the process config, including container overrides. Fix: - Add an `initialized` flag to track whether config has been applied - Make initialize() idempotent by checking the flag - Always call initialize() in createTaskProcessor() (safe due to idempotency) - Reset initialized flag in clone() so cloned processes can be re-initialized This ensures that when ContainersInspector calls createTaskProcessor() to create task previews, the config file settings are properly applied first. Signed-off-by: Claude <noreply@anthropic.com>
✅ Deploy Preview for nextflow-docs-staging canceled.
|
bentsherman
approved these changes
Jan 20, 2026
jorgee
approved these changes
Jan 20, 2026
bentsherman
added a commit
that referenced
this pull request
Jan 21, 2026
…6736) Co-authored-by: Ben Sherman <bentshermann@gmail.com> Signed-off-by: Ben Sherman <bentshermann@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #6734
The
nextflow inspectcommand was returning containers defined in process source files instead of the overridden values from profile configuration files (e.g., withName selectors).Root cause: In ProcessDef.createTaskProcessor(), the condition
if( !processConfig )was meant to callinitialize()if config wasn't set:nextflow/modules/nextflow/src/main/groovy/nextflow/script/ProcessDef.groovy
Lines 263 to 265 in 24cc59e
But
processConfigis always non-empty (initialized withDEFAULT_CONFIGvalues in the constructor), soinitialize()was never called through this code path.The
initialize() method is responsible for applying config file settings (withName/withLabel` selectors) to the process config, including container overrides.Fix:
initializedflag to track whether config has been appliedinitialize()idempotent by checking the flaginitialize()increateTaskProcessor()(safe due to idempotency)clone()so cloned processes can be re-initializedThis ensures that when
ContainersInspectorcallscreateTaskProcessor()to create task previews, the config file settings are properly applied first.