Repository navigation
Conversation
…walk Sequential and loop blocks decide each input's `required` flag and default in one ordered walk over their sub-blocks; `required_inputs` is derived from `inputs` as in conditional blocks, and the two overrides are gone. Composites declare their own `InputParam`/`OutputParam`/`ComponentSpec`/`ConfigSpec` for a derived entry with `*_overrides`, and get a FutureWarning until they settle a default two sub-blocks disagree on, a conditional block's per-branch defaults included. Leaf blocks declare what they write back, docstrings regenerated. Fixes #15009. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
github-actions
Bot
added
documentation
|
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
| f"{block_name}.{attr_name}['{name}'] must be of type {expected.__name__}, replacing the derived one; " | ||
| f"got {type(declaration).__name__}." | ||
| ) | ||
| items[index[name]] = declaration |
There was a problem hiding this comment.
Could the declaration name (or kwargs group) be checked against the override key? {"height": InputParam("width", default=512)} currently passes validation and replaces the public height input with width, while the child still reads height. Rejecting this mismatch would prevent a silently ineffective override.
| f"`input_overrides` on {self.__class__.__name__} to pick the default explicitly.", | ||
| standard_warn=False, | ||
| ) | ||
| if isinstance(block, ConditionalPipelineBlocks) and block.default_block_name is None: |
There was a problem hiding this comment.
Could guaranteed outputs be derived from every reachable branch, including nested composites? A conditional with a default branch can still produce different output sets; treating its union as guaranteed drops a later required input even when the selected branch never produces it. Wrapping a skippable conditional in a sequence has the same problem.
| if description is not None: | ||
| instance.description = description | ||
| for name, value in ( | ||
| ("input_overrides", input_overrides), |
There was a problem hiding this comment.
Could get_execution_blocks() preserve applicable overrides when it calls from_blocks_dict()? An input overridden to 0.9 currently reverts to the leaf default 0.3 in the extracted blocks, so initializing a pipeline from the selected workflow changes its behavior. Please cover overrides during workflow extraction.
fix #15009
related #15133