Joey Harrington

Just as a thought -- this could be alleviated by adjusting the retry logic. One downside to this is that the shutdown endpoint allows requesting multiple slaves be shutdown, so...

The recent changes to add request timeouts and better error handling have improved this very slightly (the expiration of the timeout is handled more gracefully now, no more big stack...

This also causes at least one functional test to wait unnecessarily during tearDown. `test_failed_setup_does_not_kill_slave` intentionally creates a build that fails with an error. When the functional test framework hits tearDown...

To be more specific, I was unable to get this working while running a python script via git bash on windows.

That's a good point -- this could still be an issue even with only a single slave on a host because of multiple executors.

Downgrading to minor since this should only ever occur as fallout from some other bug. The original bug that led to this issue being filed was fixed, so this is...

API versioning is in now. Effort for this would be pretty small.

A concrete downside to the lack of coordination across threads is that one thread may time out on its requests and trigger slave shutdown, and during shutdown it's then possible...

Fixing build cancellation would solve part of this problem (the client can cancel a job when it has taken longer than it wants to wait). Currently cancellation will not interrupt...

@aptxkid :+1: -- actually it is in there (`clusterrunner shutdown`) but we should add documentation on the website.