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
Talking with @natefoo in private it was decided maybe we should open an issue for a conversation about workflow invocation, our investigations, etc.
$ journalctl -u galaxy-handler@1 --since '5 days ago' | grep 'invocation 60463 delayed' | wc -l
55270
$ journalctl -u galaxy-handler@1 --since '5 days ago' | grep 'invocation 60463 delayed' | head -n 1
May 28 14:03:32 ...
Most steps were in new, only a couple scheduled, and only one with a job ID. I just kinda assumed if job was scheduled it would have an ID? I guess not?
I've got two of these right now, in one case the user deleted a job and the remaining jobs that had been created were paused. In another, a job ended in error and the downstream jobs were set to paused.
Looping these invocations seems to consume a huge amount of memory.
Talking with @natefoo in private it was decided maybe we should open an issue for a conversation about workflow invocation, our investigations, etc.
Most steps were in new, only a couple scheduled, and only one with a job ID. I just kinda assumed if job was scheduled it would have an ID? I guess not?
Logs are full of these messages for some recent workflows and isn't clear that they will ever complete.
The text was updated successfully, but these errors were encountered: