Repository navigation
[modular] Per-workflow input signature in the docstring of blocks with _workflow_map #15208
Description
Follow-up to #15136.
For the final assembled blocks that support workflows (the ones with _workflow_map, i.e. the auto blocks a checkpoint maps to), the signature and the docstring aren't informative enough. An input is listed, but you don't know which workflow actually uses it, whether it's required there, or what its default is, since the defaults can differ between workflows.
Today the way to see the exact signature is to prune the blocks with get_workflow(name) and look at .inputs on the result. That works, but it is better to put that information in the docstring for the users.
This PR proposes a better docstring for these blocks, limited to blocks that define _workflow_map: per workflow, the inputs it takes with their required flag and default, with the inputs that are the same in every workflow listed once.
Examples
AnimaAutoBlocks
Today (after #15136):
Supported workflows:
- `text2image`: requires `prompt`
- `img2img`: requires `image`, `prompt`
Inputs:
prompt (`str`):
The prompt or prompts to guide image generation.
negative_prompt (`str`, *optional*):
...
image (`Image | list`, *optional*, depends on the workflow, see `vae_encoder`):
Reference image(s) for denoising. Can be a single image or list of images.
...
strength (`float`, *optional*, defaults to 0.9):
Strength for img2img/inpainting.
...
image is optional in the list but required for img2img. strength reads like a general input, but text2image does not use it.
Proposed:
Supported workflows:
- `text2image`: requires `prompt`
- `img2img`: requires `image`, `prompt`
Inputs (all workflows):
prompt (`str`):
The prompt or prompts to guide image generation.
negative_prompt (`str`, *optional*):
...
num_inference_steps (`int`, *optional*, defaults to 50):
...
Inputs (`img2img`):
image (`Image | list`):
Reference image(s) for denoising. Can be a single image or list of images.
strength (`float`, *optional*, defaults to 0.9):
Strength for img2img/inpainting.
MiniMaxH3Blocks
Today:
Supported workflows:
- `t2va`: requires `prompt`
- `fl2va`: requires `prompt`, `image` or `prompt`, `last_image`
- `ref2va`: requires `prompt`, `references`
Inputs:
...
references (`list`, *optional*, depends on the workflow, see `...`):
...
num_frames (`int`, *optional*):
Number of frames to generate, at the fixed 24 fps. ...
image (`Image`, *optional*):
...
last_image (`Image`, *optional*):
...
num_frames shows as optional with no default. In t2va and fl2va it defaults to 124, in ref2va it is required (the model reads the length from the references). The docstring can't say that today.
Proposed:
Inputs (all workflows):
prompt (`str`):
...
height (`int`, *optional*):
...
Inputs (`t2va`, `fl2va`):
num_frames (`int`, *optional*, defaults to 124):
Number of frames to generate, at the fixed 24 fps. ...
Inputs (`fl2va`):
image (`Image`, *optional*):
...
last_image (`Image`, *optional*):
...
Inputs (`ref2va`):
references (`list`):
...
num_frames (`int`):
Number of frames to generate, at the fixed 24 fps. ...
Each per-workflow section is get_workflow(name).inputs minus what is already in the shared list. The same renderer change applies to the model-card doc in modular_pipeline_utils.py, which already loops over _workflow_map but only prints the trigger inputs.
Posted by Claude Code on behalf of @yiyixuxu.
Activity
[modular] docstring says "depends on the workflow" for a per-branch i…
voropaevv commentedon Nov 9, 2026
I'd like to contribute an AI-assisted patch for this follow-up to #15136. The local patch uses each resolved workflow's input specs in the block docs and model card, with identical entries listed once. I checked Anima and MiniMax H3 without loading model weights. Would you be open to this PR, and should I wait for #15136 to merge before opening it?
yiyixuxu commentedon Nov 9, 2026
we are not looking for PR contribution for this issue
feel free to share your thoughts/feedbacks on design etc. we will add you as a co-author if your feedback is used in our PR
voropaevv commentedon Nov 10, 2026
At
c2667549(#15136), the model-card renderer raises on MiniMax H3'sfl2vabecause it calls.keys()on a tuple of trigger sets (prompt+imageorprompt+last_image).format_workflowalready renders both alternatives. Keeping that summary separate lets the input rows come directly fromget_workflow(name).inputs.I'd share the grouping logic between
.docand the model card. Use the displayed spec to distinguish rows with different requiredness or defaults, and group identical rows by the workflows that use them. If a workflow cannot be resolved, show that in its section. Use "all workflows" only when the row is present in every declared workflow.In an AI-assisted prototype based on
c2667549, both renderers matched the resolved input names, requiredness, and displayed defaults for all five Anima and MiniMax H3 workflows. The check ran without loading model weights.