Question, so in UI, if you load a task-run from a flow-run, there is a graphql query that runs (below), is it intended to use the null input to the variables? This seems wrong, but I don’t see a bug report for it. In our heavy use environments this is causing apollo to crash to the memory heap size limit. In our testing environment, converting that query to an aggregate, I have a count of 4695267. Version 0.15.3 of all components

query taskRunParent($flowRunId: uuid, $taskId: uuid) {
  task_run(
    where: {_and: [{flow_run_id: {_eq: $flowRunId}}, {task_id: {_eq: $taskId}}]}
  ) {
    id
    __typename
  }
}

variables: {
  "taskId": null,
  "flowRunId": null
}

Hi @Joe McDonald - this is valid but I can see where the issue arises. I think we can infer the info that's returning from elsewhere with the global store so it should be safe to remove. I'll open a PR 👍

@nicholas Thanks, yea we don’t see this issue in dev environments because it’s used for very little testing, but in our beta where we run 100s of flows per day for testing it has become an issue as it does cause apollo to crash… that’s another thing to work on separate from the UI making a call that, if successful would return around 500Mb of data.

That's a big call 😅

@nicholas just to confirm that this change has improved loading of task-run pages in all of our environments and it works great now to look at details w/o crashing apollo in environments with lots of task-runs. PS - I also found that apollo wasn’t utilizing all system memory due to a default limitation of Node. Setting

NODE_OPTIONS="--max-old-space-size=4096"

worked to stop the crashing before the release was available, even though the query still timed out it didn’t come OOM killer to step in.

That’s fantastic, thank you for letting us know!