Repository navigation
Warn when a copy of pipeline.blocks is modified #15067
Description
ModularPipeline.blocks returns a copy, so modifying it (e.g. pipe.blocks.sub_blocks.insert(...)) does not change the pipeline. This is intentional and documented (see the note under init_pipeline), but some users may assume they can modify the pipeline this way (see #12386). It would be better to warn and point to the correct approach: modify the blocks, then create a new pipeline with blocks.init_pipeline().
Posted by Claude Code on behalf of @yiyixuxu, with their approval.
Activity
Andromedan-Organism commentedon Oct 18, 2026
Checked the page on the diffusers documentation and went through the warning (see screen snip attached). Could you please assign the issue to me? I'll begin working on this asap.
yiyixuxu commentedon Oct 22, 2026
@TherealArithmeticProgression
can you described your approach briefly here?
Andromedan-Organism commentedon Oct 22, 2026
@yiyixuxu
sure, sorry the first message was kinda barren.
Basically, the approach is to make the returned copy’s sub_blocks (InsertableDict) log a warning on mutation (insert, pop, item assignment). The message would say that modifying pipe.blocks doesn’t change the pipeline(akin to a message shared in the prev img), and to modify the blocks and call blocks.init_pipeline() to create a new one. Read-only use (print, get_workflow, sub_blocks[...] etc) will stay silent. A flow like blocks = pipe.blocks --> blocks.sub_blocks.insert(...) --> blocks.init_pipeline()
... would also warn under this approach. (Is that acceptable, or is it more acceptable to only warn when mutating pipe.blocks directly?)
Tests: Mutating the copy warns, another test that reading doesn’t raise the warn, and one that the copy still works with init_pipeline().
Tests in the repo use logger.warning so I'll stick to that (not warnings.warn) - any other details I can share?
(ps: my username was recently updated from TherealArithmeticProgression to Andromedan-Organism))