Library name and version
azure-mgmt-datafactory 9.2.0 and 10.0.0 (latest)
Describe the bug
An ExecuteDataFlowActivity's data-flow reference is silently lost when a pipeline is read (or round-tripped) through the SDK model. The service serializes the reference as lowercase typeProperties.dataflow, but the generated model maps the data_flow attribute to typeProperties.dataFlow (capital F). On deserialization the lowercase key is unmatched, data_flow becomes None, and it disappears from serialize() — so pipelines.get(...).serialize() returns the activity without its data-flow reference, and any edit written back via pipelines.create_or_update(...) drops it entirely, turning a working Data Flow activity into a no-op.
Its sibling typeProperties fields (compute, staging, traceLevel) survive, because their casing matches the model — which makes the loss easy to miss.
Casing, per Microsoft's own docs: the Data Flow activity reference documents the property as lowercase dataflow (and the Type-properties table lists dataflow as Required). The model, however:
>>> from azure.mgmt.datafactory.models import ExecuteDataFlowActivity
>>> ExecuteDataFlowActivity._attribute_map["data_flow"]
{'key': 'typeProperties.dataFlow', 'type': 'DataFlowReference'}
In 10.0.0 the same mismatch is present (data_flow: DataFlowReference = rest_field(name="dataFlow")).
Expected behavior
pipelines.get(...) should populate data_flow, and serialize() / create_or_update(...) should round-trip the reference. i.e. the model key should match what the service emits (dataflow).
Actual behavior
data_flow deserializes to None; the reference is absent from serialize(); a round-tripped pipeline loses it.
Reproduction Steps
No Azure resources or credentials needed — the loss is at the model boundary:
from azure.mgmt.datafactory.models import Activity, ExecuteDataFlowActivity
print(ExecuteDataFlowActivity._attribute_map["data_flow"])
# {'key': 'typeProperties.dataFlow', 'type': 'DataFlowReference'}
# 'dataflow' (lowercase) is exactly what the service returns for this activity
act = Activity.deserialize({
"name": "df",
"type": "ExecuteDataFlow",
"typeProperties": {
"dataflow": {"referenceName": "MyFlow", "type": "DataFlowReference"},
"compute": {"computeType": "General", "coreCount": 8},
"traceLevel": "Fine",
},
})
print(type(act).__name__) # ExecuteDataFlowActivity
print(act.data_flow) # None <-- reference lost
print(act.serialize()["typeProperties"])
# {'compute': {'computeType': 'General', 'coreCount': 8}, 'traceLevel': 'Fine'}
# ^ no 'dataflow'/'dataFlow' — compute & traceLevel survived, the reference did notConfirmed live against a real ADF factory: a pipeline whose Data Flow activity executes correctly returns via pipelines.get(...) with no data-flow reference in the serialized output; the raw ARM REST response for the same pipeline contains typeProperties.dataflow (lowercase).
Prior reports
This has been reported and closed several times without a fix, most recently auto-closed by the stale bot (which invites a fresh issue):
Suggested fix
Change the generated key for ExecuteDataFlowActivity.data_flow from dataFlow to dataflow (in the TypeSpec/Swagger the SDK is generated from), so it matches what the ADF service actually emits and accepts. If the service genuinely also accepts dataFlow, the mismatch is still worth resolving in the spec so get→serialize/create_or_update round-trips are lossless.
Library name and version
azure-mgmt-datafactory 9.2.0 and 10.0.0 (latest)
Describe the bug
An
ExecuteDataFlowActivity's data-flow reference is silently lost when a pipeline is read (or round-tripped) through the SDK model. The service serializes the reference as lowercasetypeProperties.dataflow, but the generated model maps thedata_flowattribute totypeProperties.dataFlow(capital F). On deserialization the lowercase key is unmatched,data_flowbecomesNone, and it disappears fromserialize()— sopipelines.get(...).serialize()returns the activity without its data-flow reference, and any edit written back viapipelines.create_or_update(...)drops it entirely, turning a working Data Flow activity into a no-op.Its sibling
typePropertiesfields (compute,staging,traceLevel) survive, because their casing matches the model — which makes the loss easy to miss.Casing, per Microsoft's own docs: the Data Flow activity reference documents the property as lowercase
dataflow(and the Type-properties table listsdataflowas Required). The model, however:In 10.0.0 the same mismatch is present (
data_flow: DataFlowReference = rest_field(name="dataFlow")).Expected behavior
pipelines.get(...)should populatedata_flow, andserialize()/create_or_update(...)should round-trip the reference. i.e. the model key should match what the service emits (dataflow).Actual behavior
data_flowdeserializes toNone; the reference is absent fromserialize(); a round-tripped pipeline loses it.Reproduction Steps
No Azure resources or credentials needed — the loss is at the model boundary:
Confirmed live against a real ADF factory: a pipeline whose Data Flow activity executes correctly returns via
pipelines.get(...)with no data-flow reference in the serialized output; the raw ARM REST response for the same pipeline containstypeProperties.dataflow(lowercase).Prior reports
This has been reported and closed several times without a fix, most recently auto-closed by the stale bot (which invites a fresh issue):
Suggested fix
Change the generated key for
ExecuteDataFlowActivity.data_flowfromdataFlowtodataflow(in the TypeSpec/Swagger the SDK is generated from), so it matches what the ADF service actually emits and accepts. If the service genuinely also acceptsdataFlow, the mismatch is still worth resolving in the spec soget→serialize/create_or_updateround-trips are lossless.