Skip to content

fix(plugin-typescript): add a timeout to the Algolia auto-types lookup#7206

Open
sebdanielsson wants to merge 1 commit into
yarnpkg:masterfrom
sebdanielsson:claude/berry-7111-fix-8doaul
Open

fix(plugin-typescript): add a timeout to the Algolia auto-types lookup#7206
sebdanielsson wants to merge 1 commit into
yarnpkg:masterfrom
sebdanielsson:claude/berry-7111-fix-8doaul

Conversation

@sebdanielsson

@sebdanielsson sebdanielsson commented Jun 27, 2026

Copy link
Copy Markdown

What's the problem this PR addresses?

Closes #7111

yarn add queries Algolia's npm-search index to detect whether the added package needs a matching @types package. In our corporate network, all egress traffic traverses our HTTP proxy. If this is set globally using HTTPS_PROXY, HTTP_PROXY, and NO_PROXY, but not explicitly with Yarn's HTTP proxy config, this query will not go through the proxy but will instead try to make a direct connection. In our case, this means the firewall silently drops the connection.

httpTimeout is not what's bounding a single attempt. I dropped it from 15s to 10s and got an identical ~135s per attempt. The wait is the Linux kernel's TCP SYN-retry exhaustion (default tcp_syn_retries=6, ~127–135s in my tests). Because the TCP socket never establishes, got's timeout.socket (which is socket-inactivity-after-connect) never starts. Got then retries httpRetry times, which multiplies the dead time.

My tests:

Settings Total Per attempt Attempts
httpTimeout=10s httpRetry=0 135s ~135s 1
httpTimeout=10s httpRetry=1 269s ~135s 2
httpTimeout=15s httpRetry=1 270s ~135s 2
Defaults (httpTimeout=1m httpRetry=3) 546s (~9m) ~135s 4

How did you fix it?

This caps the lookup at 10s and, on timeout or network failure, warns the user (pointing at the tsEnableAutoTypes: false / YARN_TS_ENABLE_AUTO_TYPES="false" escape hatch) before letting the install proceed without the @types package. It also hardens the Algolia requester so a connection error without a response no longer throws an unrelated TypeError.

Future fixes

My last comment in the linked issue proposes additional fixes to make this more stable, but I wanted to keep this PR small and easy to review. A future enhancement would be to have the Algolia lookup respect the global HTTP environments, just like the installation does today.

Checklist

  • I have set the packages that need to be released for my changes to be effective.
  • I will check that all automated PR checks pass before the PR gets reviewed.

`yarn add` queries Algolia's `npm-search` index to detect whether the added
package needs a matching `@types` package. On restricted networks (eg. a
corporate proxy that drops or refuses the request) this lookup had no timeout
and could make `yarn add` hang indefinitely, while `yarn install` kept working
against the configured registry.

This caps the lookup at 10s and, on timeout or network failure, warns the user
(pointing at the `tsEnableAutoTypes: false` / `YARN_TS_ENABLE_AUTO_TYPES="false"`
escape hatch) before letting the install proceed without the `@types` package.
It also hardens the Algolia requester so a connection error without a `response`
no longer throws an unrelated `TypeError`.

Closes yarnpkg#7111

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NS1JKnVAz9uPwdyUhfub2g
@sebdanielsson

Copy link
Copy Markdown
Author

CI failures seem to be pre-existing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug?]: yarn add unexpectedly hangs in network restricted environments

2 participants