@vercel/connect: accept an AbortSignal on getToken / getTokenResponse / startAuthorization / revokeToken / getConnectorMetadata

Summary

None of @vercel/connect's network calls can be cancelled or bounded by the caller. Each issues fetch with only method, headers and body, and no options type accepts an AbortSignal or a timeout.

Version

@vercel/connect 2.0.4 and 2.1.0.

Evidence

• dist/token.js — getTokenResponse (and so getToken) and revokeToken: fetch(endpoint, { method, headers, body }).
• dist/authorization.js — startAuthorization: same shape, with the OIDC token read inside the same unbounded stretch.
• dist/connector.js — getConnectorMetadata, and dist/installation.js: same.
• ConnectOptions accepts vercelToken, forceRefresh, region; ConnectAuthorizationOptions accepts vercelToken, callbackUrl, webhook, deviceCode, expiresInMs, prompt, region. Neither has signal.
• AbortSignal, AbortController, signal and timeout occur 0 times across dist/ (82 files at 2.0.4, 84 at 2.1.0), while fetch( occurs 10 times.

Use case

These calls usually sit on a latency-sensitive path: minting a token while a bot composes a reply, or startAuthorization right before redirecting a user to a consent screen. An app wants a budget — fail fast after a few seconds and offer a retry — instead of waiting on runtime-level timeouts or the function's max duration. Today the only option is Promise.race, which abandons the promise but leaves the request (and the OIDC read before it) running, with no way to cancel it.

Proposal

Add signal?: AbortSignal to ConnectOptions, ConnectAuthorizationOptions and the installation options, and forward it to fetch (and to the OIDC token read where possible). getTokenResponse only writes its cache after a successful response, so an aborted call leaves the cache untouched.