You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- type: yaml
transforms:
# Define the first transform of type "RaiseElementToPower"
RaiseElementToPower:
config_schema:
properties:
n: {type: integer}
body:
type: MapToFields
config:
language: python
append: true
fields:
power: "element ** {{n}}"
# Define a second transform that produces consecutive integers.
Range:
config_schema:
properties:
end: {type: integer}
# Setting this parameter lets this transform type be used as a source.
requires_inputs: false
body: |
type: Create
config:
elements:
{% for ix in range(end) %}
- {{ix}}
{% endfor %}
and indicate the following use of the provided transforms:
transforms:
- type: Range
config:
end: 10
- type: RaiseElementToPower
input: Range
config:
n: 3
...
However, providing and using RaiseElementToPower in this manner results in an error. For example, if the provider stanza is in provider.yaml and the following pipeline is run:
Then the following error occurs: ValueError: Invalid transform specification at "RaiseElementToPower" at line 7: Missing inputs for transform at "MapToFields" at line 1
This error also occurs when the pipeline does not use type: chain and instead specifies each transform's inputs.
The format of the provider body definition seems to be the source of the issue. Related tests in the source do not exercise this style of provider definition and only cover the block string literal style used in Range above and the 'chain' style. For example:
Previously the fact that a transform had inputs was not propagated
to the recursive transform creation, resulting in a validation error.
This fixesapache#34646.
robertwb
added a commit
to robertwb/incubator-beam
that referenced
this issue
Apr 21, 2025
What happened?
The Beam YAML provider docs show the following example provider configuration:
and indicate the following use of the provided transforms:
However, providing and using
RaiseElementToPower
in this manner results in an error. For example, if the provider stanza is inprovider.yaml
and the following pipeline is run:Then the following error occurs:
ValueError: Invalid transform specification at "RaiseElementToPower" at line 7: Missing inputs for transform at "MapToFields" at line 1
This error also occurs when the pipeline does not use
type: chain
and instead specifies each transform's inputs.The format of the provider
body
definition seems to be the source of the issue. Related tests in the source do not exercise this style of provider definition and only cover the block string literal style used inRange
above and the 'chain' style. For example:Issue Priority
Priority: 2 (default / most bugs should be filed as P2)
Issue Components
The text was updated successfully, but these errors were encountered: