Maybe related to  issue 917813 ?

Taking as a trooper. The problem seems to be not with this particular test, but with the swarming pool running the tests, since many other isolated tests are pending for a long time (just like this one), adding to the runtime of the builder and ultimately making it time out at 3h. Either the pool is insufficient, or some tests are taking too much resources and exhausting the pool.

Confirmed the capacity problem: http://shortn/_BYeyA1oRKg (internal link).

I'll see if we have the resources to add the capacity. Raising priority, since it paged me today because of this issue.

I'll continue the internal investigation in http://irm/incidents/a.e9HzQJiAMQfdkVp9zKGQ

Is this also causing issues for bots in the luci.flex.try pool, or is that a separate issue? I have https://ci.chromium.org/p/pdfium/builders/luci.pdfium.try/win/12840 here that's been pending for half an hour.

Issue 921827 has been merged into this issue.

#9 - no, it shouldn't interfere with luci.flex.try pool - it's a completely separate pool of machines.

Issue 921943 has been merged into this issue.

From issue 921943 and CL https://crrev.com/i/776610 - we should justify any further capacity increase. Chances are, some tests were added over time without capacity considerations. We should check if those tests are indeed absolutely needed.

Who will be an approver of capacity increase?

Note: network_service_browser_tests and browser_tests are top 2 resource consumer.
More than half of win10 pool seems used by these 2 tests.
https://plx.corp.google.com/scripts2/script_5c._3cf21e_0000_2bcb_926c_089e0832afdc

Issue 922336 has been merged into this issue.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infradata/config/+/5744e7432530c5f09e50bd8f2839227f60018dfc

commit 5744e7432530c5f09e50bd8f2839227f60018dfc
Author: Takuto Ikuta <tikuta@google.com>
Date: Mon Jan 21 11:52:27 2019