Identify why `find_proxy()` is slow for us and work with upstream `Faraday` maintainers to fix

[jeffwidman]

Is there an existing issue for this?

• I have searched the existing issues

Code improvement description

@jakecoffman discovered that Faraday's find_proxy is slow, so added a bypass to avoid calling it:

• fix Faraday find_proxy slowness #6853

However, we later had to modify another call because a library we use also called find_proxy under the covers:

• avoid find_proxy which is slow #6859

This could happen in the future if we switch to a library that's calling find_proxy. So ideally we debug further to identify why find_proxy is slow and report (and possibly fix) upstream, rather than just working around it.

Filing an issue here so we don't forget about this.

[jeffwidman]

@jakecoffman did some poking at production, and our jobs didn't appear to speed up after this change.

So this slowness was only happening in the smoke test environment, not our production environment... unclear why, probably something is different about the docker environment, and the failure mode of hanging for a while and then continuing makes me think Faraday makes some linux call, and then wait for it to timeout before falling back to another mode so maybe an env var needs setting??

[github-actions]

👋 This issue has been marked as stale because it has been open for 2 years with no activity. You can comment on the issue to hold stalebot off for a while, or do nothing. If you do nothing, this issue will be closed eventually by the stalebot. Please see CONTRIBUTING.md for more policy details.