This only happens when you are querying multiple builds. What's going on is that a stream was registered, but its logs never made it, so LogDog is blocking assuming that it is streaming. This bug has been filed before, by either you or akeshet@, and the short answer is that there isn't much that we can do. Once the build times out (~24hr) it should load again because the stream is known to be empty at that point; until then, LogDog can't tell if the stream is going to send data some day.

The best effort workaround, if you'll recall, bought a few more log lines, but isn't that much better than no workaround :(

Ah... the 24 hour timeout is reasonable, and what I was thinking of.

After we move to swarming, and don't have to deal with the way buildbot kills builds, will this go away?

Swarming can still kill builds, unfortunately, for similar reasons, so I don't think that will change much/anything. The real "solution" is to just click the specific log stream that you care about.

Hum... the only reason I normally use "All" is to find the actual message from buildbot about why it's killing the build. This is an expensive way to find a 5 line message.

If that were in a predictable place that would also resolve this nicely.

In both BuildBot and Swarming, that message is emitted outside of the scope of LogDog - in BuildBot, in the "stdio" link (b/c that's BuildBot's STDIO) and in Swarming, it will be in the raw task output and/or task metadata.

From discussion it seems like this is WontFix. Removing from our untriaged queue.

It's been > 24 hours, and it still hangs.