Comfy-Org/ComfyUI · critical · ValueError

Bad block_type

Error message

Bad block_type

What it means

Chroma calculates modulation-vector offsets for its single and double transformer blocks via calc_double_or_single_modulation. Callers must pass block_type 'double_img' or 'double_txt'; anything else falls through to raise ValueError('Bad block_type'). In practice this is an internal invariant: both call sites in forward_orig pass literal strings, so a user seeing this error means custom/patched code invoked the offset helper with a wrong literal.

Source

Thrown at comfy/ldm/chroma/model.py:140

            return (tensor[:, -2:-1, :], tensor[:, -1:, :])
        single_block_count = self.params.depth_single_blocks
        double_block_count = self.params.depth
        offset = 3 * idx
        if block_type == "single":
            return ChromaModulationOut.from_offset(tensor, offset)
        # Double block modulations are 6 elements so we double 3 * idx.
        offset *= 2
        if block_type in {"double_img", "double_txt"}:
            # Advance past the single block modulations.
            offset += 3 * single_block_count
            if block_type == "double_txt":
                # Advance past the double block img modulations.
                offset += 6 * double_block_count
            return (
                ChromaModulationOut.from_offset(tensor, offset),
                ChromaModulationOut.from_offset(tensor, offset + 3),
            )
        raise ValueError("Bad block_type")


    def forward_orig(
        self,
        img: Tensor,
        img_ids: Tensor,
        txt: Tensor,
        txt_ids: Tensor,
        timesteps: Tensor,
        guidance: Tensor = None,
        control = None,
        transformer_options={},
        attn_mask: Tensor = None,
    ) -> Tensor:
        transformer_options = transformer_options.copy()
        patches_replace = transformer_options.get("patches_replace", {})

        # running on sequences img

View on GitHub (pinned to 1c6d8d45b3)

Solutions

1. Pass exactly 'double_img' or 'double_txt' as block_type
2. If the call comes from a custom node patch of Chroma, update the node to match the current block_type vocabulary in comfy/ldm/chroma/model.py
3. Remove stale monkey-patches of forward_orig so the shipped implementation runs

Example fix

# before
mod = model.calc_modulations(vec, block_type="single")

# after
mod = model.calc_modulations(vec, block_type="double_img")

VALID_BLOCK_TYPES = {"double_img", "double_txt"}
assert block_type in VALID_BLOCK_TYPES, f"block_type must be one of {VALID_BLOCK_TYPES}"

def is_valid_chroma_block_type(bt: str) -> bool:
    return bt in {"double_img", "double_txt"}

When it happens

Trigger: Calling ChromaModulationOut / the modulation offset helper (model.py around line 120-140) with block_type values like 'single', 'img', 'double' or a typo such as 'double_image'. Standard ComfyUI sampling never passes anything but 'double_img'/'double_txt'.

Common situations: Custom model patches or nodes that reimplement Chroma's modulation slicing; copy-pasting code from flux model.py where the block_type vocabulary differs; monkey-patched forward_orig from an out-of-date custom node.

Related errors

• Hidden size {params.hidden_size} must be divisible by num_he
• Got {params.axes_dim} but expected positional dim {pe_dim}
• Input img and txt tensors must have 3 dimensions.
• Attempt to create ChromaRadiance object without setting oper
• Unknown key(s) in transformer_options chroma_radiance_option

AI-assisted analysis of Comfy-Org/ComfyUI@1c6d8d45b3 (2026-08-14). Data as JSON: /api/errors/7383d3d6de010411. Report an issue: GitHub.