Add tests and agent docs for kwargs_type input/output#14157
Conversation
…pelines Document how kwargs_type-tagged values flow from block outputs and user inputs to consumer blocks (the mechanism behind denoiser_input_fields), pin the behavior down with tests, and add a key-pattern section to .ai/modular.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
github-actions
Bot
added
size/M
sayakpaul
left a comment
sayakpaul
left a comment
There was a problem hiding this comment.
Thanks for the work and I left some comments.
I found it a bit confusing as a user as to when one should use, for example, pipe(a="testa", ...) and when one should use pipe(typea={"a": "testa"}). Maybe we could simplify that a bit (can be in a different PR and doesn't have to block this one).
|
|
||
| def __call__(self, components, state: PipelineState) -> PipelineState: | ||
| block_state = self.get_block_state(state) | ||
| assert block_state.typea == block_state.expected_typea |
There was a problem hiding this comment.
I am a bit confused here.
I'd imagine that the block_state.typea and block_state.expected_typea are different state-level components. But seems like they are the same. In what circumstance, a user would want to define input params like that?
There was a problem hiding this comment.
it's for testing only, the expcted_typea is the value we expect to receive in block_state for typea, and we use only use it for assert statement inside the block - but i restructured the test to make it lesss confusing
| blocks = SequentialPipelineBlocks.from_blocks_dict( | ||
| {"producer": DummyKwargsProducerStep(), "consumer": DummyKwargsConsumerStep()} | ||
| ) | ||
| pipe = blocks.init_pipeline() |
There was a problem hiding this comment.
When pipe is constructed, should we also assert against the params accepted by the call method of pipe?
…est pipeline call params Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2 participants
add tests and docs for
kwargs_type, which comes very handy for cosmos3