Repeated requests to retrieve missing icon
If an workflow has references to either actions from a pack not yet installed, or a task has no action, it is unable to display an icon for that task.
It repeatedly requests that icon, hundreds of times. You can see it 'flickering'

For actions with no task, they should use https://github.com/StackStorm/st2flow/blob/master/static/icon.png
This does not seem to be shipped with st2flow 3.0-dev34. I think it's closely related to https://github.com/StackStorm/st2flow/issues/310 - basically we're no longer including that flow/static directory, and we either should include it, or update all our references.
It's also a problem that it repeatedly requests resources - if it gets a 404 it should just accept that, and stop trying to reload it.
The app is attempting to load the default when the pack icon cannot be found, using an error handler. See https://github.com/StackStorm/st2flow/pull/252 . However, when the default icon is missing (in this case, because the static folder wasn't included in assets) the error handler isn't checking whether the error was caused by the default icon not being available -- it was assuming that the only error case was the pack didn't have an icon. Easy fix on the client side to check whether the image src is already the default.
@LindsayHill Is this still an issue now that static folder exists?
I don't see the behavior any more, now that the icon loads.
There's two parts to this though: 1/ Icon missing 2/ Constant attempts to get missing icon
The first bit is sorted, which is most important. I think the second behavior is still there, and may cause issues with packs with missing icons. Have not checked that behavior.
Yeah, I'll look when I focus on this item. I'm hoping that there's a simple logic similar to load_icon(pack) and if failed == true {load_icon(default)} which would send it into an endless loop if default icon doesn't exist - but I'll confirm/disprove this when I triage.
Low priority for now though - not a blocker for 3.0.