[JENKINS-23592] Do not block indefinitely on information from slaves

If some of your slaves claim to be online but are not fully responsive, some support components may be very slow to yield results. That conflicts with the expectation that a support bundle be produced quickly. (Currently bundles generated on demand are in fact produced in an HTTP response thread, which might need to be revisited.) Or if a slave has recently dropped offline, you are probably interested in what it was doing.

In particular, thread dumps and slave logs both currently require slave connectivity.

It would be better to set a clear time limit for a request for such information, say one second, after which this report is simply skipped.

It may also be a good idea to cache the last such successful report on the master. If obtaining current data times out, include the last known data, with a note that it may be stale. In the case of the slave log, which rarely changes, you could even pass in a checksum of the prior data, so that the slave can just return a "not-modified" flag if the content has not changed.

---
Originally reported by jglick, imported from: Do not block indefinitely on information from slaves

• status: Open
  
• priority: Major
  
• component(s): support-core-plugin
  
• label(s): performance, remoting, robustness
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 2
  
• imported: 20251212-090250
  

If some of your slaves claim to be online but are not fully responsive, some support components may be very slow to yield results. That conflicts with the expectation that a support bundle be produced quickly. (Currently bundles generated on demand are in fact produced in an HTTP response thread, which might need to be revisited.) Or if a slave has recently dropped offline, you are probably interested in what it was doing.


In particular, thread dumps and slave logs both currently require slave connectivity.


It would be better to set a clear time limit for a request for such information, say one second, after which this report is simply skipped.


It may also be a good idea to cache the last such successful report on the master. If obtaining current data times out, include the last known data, with a note that it may be stale. In the case of the slave log, which rarely changes, you could even pass in a checksum of the prior data, so that the slave can just return a "not-modified" flag if the content has not changed.

Start by locating the support components that collect thread dumps and slave logs, then trace how they request information from slaves. Define the timeout and fallback behavior, including whether cached reports are required, and verify that support bundles no longer wait indefinitely.

Written by the indexing model from the issue text.