Feature Area
/area sdk
What feature would you like to see?
I would like to see comprehensive edge-case validation and regression
coverage for component I/O type handling in the Kubeflow Pipelines SDK.
As the SDK supports increasingly rich Python type annotations, including
Pydantic BaseModel-based component inputs and outputs, it would be useful
to explicitly define and test how these types are handled during component
compilation and serialization.
The proposed test coverage would include:
- Primitive parameter types
- Optional / nullable parameters
- PEP 604 union types (
A | B)
- Keyword-only arguments
- Pydantic
BaseModel inputs and outputs
- Nested structured types
- Invalid or unsupported annotations
- Serialization/deserialization
- Component compilation and generated interfaces
Where testing identifies an incorrect behavior, the corresponding minimal
SDK fix should be included.
What is the use case or pain point?
Component I/O type handling is a fundamental part of the KFP SDK because
Python type annotations influence how components are compiled and how their
interfaces are represented.
Insufficient coverage of edge cases can allow regressions to enter the SDK,
resulting in components that either fail during compilation or behave
unexpectedly when executed.
Having explicit regression coverage would:
- Make supported component I/O behavior clearer.
- Prevent regressions when the SDK's type system evolves.
- Improve confidence when introducing new structured types.
- Provide contributors with clear examples of expected SDK behavior.
- Catch compatibility issues earlier in CI rather than at pipeline runtime.
Is there a workaround currently?
Users can avoid problematic type combinations by using simpler supported
parameter types or manually converting structured objects into supported
representations.
However, these workarounds do not address the underlying lack of systematic
regression coverage.
Adding comprehensive tests would provide a long-term safety net for the SDK
and make the expected behavior of component I/O types explicit.
I would be happy to investigate the existing SDK test coverage and prepare
an implementation if maintainers agree that this would be useful.
Feature Area
/area sdk
What feature would you like to see?
I would like to see comprehensive edge-case validation and regression
coverage for component I/O type handling in the Kubeflow Pipelines SDK.
As the SDK supports increasingly rich Python type annotations, including
Pydantic
BaseModel-based component inputs and outputs, it would be usefulto explicitly define and test how these types are handled during component
compilation and serialization.
The proposed test coverage would include:
A | B)BaseModelinputs and outputsWhere testing identifies an incorrect behavior, the corresponding minimal
SDK fix should be included.
What is the use case or pain point?
Component I/O type handling is a fundamental part of the KFP SDK because
Python type annotations influence how components are compiled and how their
interfaces are represented.
Insufficient coverage of edge cases can allow regressions to enter the SDK,
resulting in components that either fail during compilation or behave
unexpectedly when executed.
Having explicit regression coverage would:
Is there a workaround currently?
Users can avoid problematic type combinations by using simpler supported
parameter types or manually converting structured objects into supported
representations.
However, these workarounds do not address the underlying lack of systematic
regression coverage.
Adding comprehensive tests would provide a long-term safety net for the SDK
and make the expected behavior of component I/O types explicit.
I would be happy to investigate the existing SDK test coverage and prepare
an implementation if maintainers agree that this would be useful.