Repository navigation
first_block cache validates clean where it won't apply (UNet pipelines; Z-Image transformer) #904
Description
Split from #897 (approved scope, 2026-10-14). cache: {"type": "first_block"} passes validation, then at run time it's only a "not applied" warning:
- SD1.5 (UNet, job c91c3bee99cd): the pipeline has no transformer. Validate can tell this from the pipeline class's components without loading anything, so a structural validate warning fits.
- Z-Image (job fb19b96cd5a7): it has a transformer, so the likely cause is a block class missing from
dw/cache_blocks.json. Confirm that first. If so, the fix is a registry entry, not a validate rule.
Model knowledge stays out of engine code: the check reads pipeline/component structure only.
Activity
dkackman commentedon Oct 14, 2026
triage: work — Don approved this scope when it was split from #897. First, check whether Z-Image's transformer block class is missing from
dw/cache_blocks.json; if it is, that's a registry entry. Then add the structural validate warning for a pipeline with no transformer component (UNet). It reads the pipeline class's components only and puts no model names in engine code. No duplicate (#875 is H3 tuning). Triage: claude-opus-5-5 / anthropic.fix(validate): #904 - warn when a cache has no transformer (UNet) or …
dkackman commentedon Oct 14, 2026
Fixed on develop @ 3bef476 (merge of fix/904-cache-unsupported-warning). The driver deploys it to mini-ai; I did not. Worked as claude-sonnet-5-5 / anthropic.
Z-Image finding: it is not a registry gap.
ZImageTransformerBlockis already registered upstream in diffusers'_helpers.py. The real cause is thatZImageTransformer2DModelin the installed diffusers has noCacheMixin, so it has noenable_cache(). The run-time "does not support enable_cache()" warning is that. Acache_blocks.jsonentry can't fix it, so I added none.Change (
dw/acceleration_warnings.py): new validate warningcache_unsupported. It reads only thecomponent_typepipeline class's constructor signature, and nothing is loaded. It fires for anycacheobject when:transformerortransformer_refparameter (UNet pipelines such as SD 1.5), orenable_cache(Z-Image).It stays silent when the class can't be resolved, takes
**kwargs, or the annotation isn't a single class. No model names are in engine code. It is a warning, never a refusal.docs/ARCHITECTURE.mdrow updated.Tests (
tests/test_validation.py): they use the realStableDiffusionPipelineandZImagePipelineclasses with no mocks. They also cover Flux withfirst_block(silent) and no cache (silent). The full suite shows the same 18 failures with and without my change (Kandinsky6 classes missing in this venv's diffusers, plus the API contract doc), so none are new.To verify:
validate_workflowon a text-to-image workflow withcomponent_typeStableDiffusionPipelineorZImagePipelineandcache: {"type": "first_block"}should return acache_unsupportedwarning. A Flux workflow with the same cache should not. This server's diffusers version determines the Z-Image result. No breaking change. I'm not proposing a regression case.dkackman commentedon Oct 14, 2026
Architecture review queued by the loop driver: this hand-off changed
dw/ordw_mcp/ondevelop(560048269d..3bef476f1b: dw/acceleration_warnings.py). The reviewer checks it againstdocs/ARCHITECTURE.mdbefore the tester verifies.dkackman commentedon Oct 14, 2026
Architecture review: pass. Reviewer run as claude-opus-5-5 / anthropic.
I read
git diff 560048269d..3bef476f1bunderdw/. The only #904 commit is 89bf498, which changesdw/acceleration_warnings.py,docs/ARCHITECTURE.mdandtests/test_validation.py. I checked it againstdocs/ARCHITECTURE.mdand item 3 ofstage-c-guardrails.md.dw.introspection.load_pipeline_class, an alias ofload_allowed_class, which is the owner the Community pipelines row names. It does not re-import by name. The step walk and paths usereferences.iter_steps/render_path, the same as the module's other checks.inspect.signature,typing.get_type_hints) plushasattr(..., "enable_cache"), which is how diffusers' ownCacheMixinshows up. No dependency inpyproject.tomlalready offers a "does this pipeline support a cache" check.CLAUDE.mdchanged.Observation, not blocking:
_CACHE_COMPONENTS = ("transformer", "transformer_ref")copies the name list thatdw/pipeline_processors/components.py:get_cache_transformerloops over. The new code's comment points at it but doesn't import it. No map row assigns that list to an owner, so the checklist gives no finding. Still, if a third denoiser name is ever added to one of the two lists, the other drifts. One shared constant would close that gap. Whether to do it is Don's call, as a consolidation item.Nothing was waived (the issue has no
arch-approved). It goes back to the tester for MCP verification.dkackman commentedon Oct 14, 2026
Verified on mps on mini-ai.lan (develop @ 29d4c4c). Tester run as claude-opus-5-5 / anthropic.
All checks are
validate_workflowcalls on inline one-step workflows, with the cache set atpipeline.configuration.cache:StableDiffusionPipeline+{"type":"first_block"}→valid: truewith the warningsteps[0].pipeline.configuration.cache: cache_unsupported: the 'first_block' cache will not be applied: StableDiffusionPipeline has no transformer component to attach a cache to (a UNet pipeline is not supported); the step runs uncached, so drop the cache.ZImagePipeline+first_block(8 steps) →cache_unsupported: ... ZImagePipeline's transformer (ZImageTransformer2DModel) does not support diffusers' enable_cache(); .... It comes alongside the existingcache_short_schedulewarning, so this server's diffusers has the same gap.FluxPipeline+first_block(20 steps) → only the no-seed warning. Nocache_unsupported.StableDiffusionXLPipeline+{"type":"faster"}→cache_unsupported: the 'faster' cache will not be applied: StableDiffusionXLPipeline has no transformer component .... The check covers any cache type, not onlyfirst_block.Each one is a warning, never a refusal, which matches the hand-off. Nothing ran on the GPU and no models were loaded.