@flyteorg/flyteidl 1.13.0-rc0 → 1.13.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -115,14 +115,12 @@ message NodeExecutionEvent {
|
|
|
115
115
|
// Indicates if this node is an ArrayNode.
|
|
116
116
|
bool is_array = 22;
|
|
117
117
|
|
|
118
|
-
// Holding this field here for now, this will be upstreamed soon.
|
|
119
118
|
// So that Admin doesn't have to rebuild the node execution graph to find the target entity, propeller will fill this
|
|
120
119
|
// in optionally - currently this is only filled in for subworkflows. This is the ID of the subworkflow corresponding
|
|
121
120
|
// to this node execution. It is difficult to find because Admin only sees one node at a time. A subworkflow could be
|
|
122
121
|
// nested multiple layers deep, and you'd need to access the correct workflow template to know the target subworkflow.
|
|
123
122
|
core.Identifier target_entity = 23;
|
|
124
123
|
|
|
125
|
-
// Holding this field here for now, this will be upstreamed soon.
|
|
126
124
|
// Tasks and subworkflows (but not launch plans) that are run within a dynamic task are effectively independent of
|
|
127
125
|
// the tasks that are registered in Admin's db. Confusingly, they are often identical, but sometimes they are not
|
|
128
126
|
// even registered at all. Similar to the target_entity field, at the time Admin receives this event, it has no idea
|