This is because now Windows build_tests are competing for the same bots used by plugins. To fix this problem we need to:

• First move capacity from the windows 10 machines to windows server.
• Move all framework-luci devicelab tests to use windows server.
• Move all framework builds to use windows server.

based on competition, shall the plugins builds remain in the queue rather than directly fail?

I thought they were failing after a few mins, the ones linked here are failing immediately which means there are 0 Windows Server machines available

https://chromium-swarm.appspot.com/botlist?c=id&c=task&c=os&c=status&d=asc&f=pool%3Aluci.flutter.try&f=os%3AWindows-Server&k=os&s=id I see machines available.

I would expect long queue time but not seeing failures immediately.

Are all these windows bots the same config of 8 cores? We used to have 32 cores bots, which flutter/plugins are currently using.

The windows machines got downgraded yesterday to use 8 cores. We need to remove the explicit dimension for 32 cores

Working on a PR to fix this.

Meta-issue question: can we make the bot status page linked from PRs give useful feedback here (e.g., "Unable to schedule job; zero available machines meet job requirements") instead of a page that just has no information and essentially a link to nowhere?

The link in checks page will link to the build details only if the task is scheduled. If failed before being scheduled, the build id will not be available.

Instead if we can obtain the taks id (like 4f86ca6c72bfff10), then it is more useful to have this link.

But as currently supported from cocoon backend, the build is triggered via buildbucket, the task id maybe not available AFAIK.

The new config has been propagated. Just retried the failed builds from the above two PRs, and they are running now.

Let's open a bug for the usability request there are many of those that we'll need to address once we have the reliability and scalability parts under control.

Created issue to track the usability: #69242.

This still doesn't seem to be resolved...
flutter/plugins#3213

That is a test/build problem https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket.appspot.com/8865161897106601168/+/steps/Run_plugin_tests/0/steps/drive_examples/0/stdout

Ohh thanks, that is being worked on as well.

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.