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
The Fields parameter in WorkflowGetRequest allows filtering response fields like status.phase or status.startedAt. However, this filtering doesn't work properly for map structures like status.nodes.
When I specify fields like status.nodes.id or status.nodes.phase, I still get all fields for all nodes. Using the exclusion pattern with -status.nodes.templateName also doesn't work.
The current Cleaner implementation doesn't respect field filtering within map values. This results in much larger responses than necessary when retrieving workflows with many nodes.
Use Cases
Reducing response size for workflows with many nodes (10 000+) to avoid GRPC message size limits
Improving performance when only specific node fields are needed
Reducing network bandwidth usage for frequent workflow status checks
Current workaround is to request only status.phase,status.startedAt,status.finishedAt and skip status.nodes entirely, but this loses important node status information.
Message from the maintainers:
Love this feature request? Give it a 👍. We prioritise the proposals with the most 👍.
The text was updated successfully, but these errors were encountered:
Summary
The
Fields
parameter in WorkflowGetRequest allows filtering response fields likestatus.phase
orstatus.startedAt
. However, this filtering doesn't work properly for map structures likestatus.nodes
.When I specify fields like
status.nodes.id
orstatus.nodes.phase
, I still get all fields for all nodes. Using the exclusion pattern with-status.nodes.templateName
also doesn't work.The current Cleaner implementation doesn't respect field filtering within map values. This results in much larger responses than necessary when retrieving workflows with many nodes.
Use Cases
Current workaround is to request only
status.phase,status.startedAt,status.finishedAt
and skipstatus.nodes
entirely, but this loses important node status information.Message from the maintainers:
Love this feature request? Give it a 👍. We prioritise the proposals with the most 👍.
The text was updated successfully, but these errors were encountered: