PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Reliable JavaScript API calls need three controls working together: a deadline so a stalled attempt ends, a retry policy limited to transient failures and repeat-safe operations, and cancellation that lets the caller stop work immediately. The browser’s fetch() promise is not an HTTP-success check—it resolves for responses such as 404—so every attempt must inspect the status before parsing. A sound wrapper creates a fresh timeout for each attempt, combines it with the caller’s AbortSignal, honors Retry-After, uses capped exponential backoff with jitter, and refuses to retry requests whose effects cannot safely be repeated.
What makes a JavaScript API request unreliable?
Failures are not limited to a server returning an error page. A request can wait indefinitely for a connection, stall while response headers or body data arrive, lose the network after a connection is opened, receive a transient 503, or be canceled by the user. Treating all of those outcomes as the same kind of failure leads to either hung interfaces or duplicate side effects.
Reliability comes from separating four decisions:
- Deadline: how long one attempt may consume before it is abandoned.
- Outcome check: whether the HTTP response is acceptable, independent of whether
fetch()fulfilled. - Retry classification: which errors and statuses are likely to succeed later.
- Cancellation: whether the caller has withdrawn interest and the operation must stop without another attempt.
These controls should live in one request wrapper rather than being reimplemented inconsistently at every call site.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Why doesn’t fetch() throw for a 404 or 500?
fetch() rejects for failures such as an inability to make the request or an abort, but an HTTP response with an error status is still a valid response at the transport level. A 404, 429, or 500 therefore fulfills the promise; inspect response.ok (true for 200–299) or response.status before reading the body.
#1 Best Overall
- Read Before You Buy — No Video Output: These adapters support charging and USB 2.0 data transfer, but cannot transmit video signals. Except for standard USB webcams (which use USB data only), they are not compatible with HDMI/DisplayPort cables, video-capable USB-C hubs, or docking stations with video output.
- Convert USB-A Ports to USB-C: Designed to connect USB-C earphones, cables, flash drives, card readers, and other USB-C accessories to standard USB-A ports. Plug-and-play with no drivers or software required.
- Aluminum Alloy Housing: Built with a sturdy aluminum alloy shell that aids in heat dissipation and protects against daily wear and scratches. Designed to maintain a stable and secure connection.
- Compact & Travel-Friendly: The ultra-compact design allows the adapter to stay plugged into your device without blocking adjacent ports or adding bulk, reducing wear and tear on your original USB ports.
- 12-Month Warranty: Backed by a 12-month manufacturer warranty for peace of mind. Designed to meet strict quality control standards for reliable everyday performance.
const response = await fetch('/api/profile');
if (!response.ok) {
// Preserve status and headers for classification and diagnostics.
throw new Error(`HTTP ${response.status}`);
}
const profile = await response.json();Do not assume that a fulfilled promise means the application operation succeeded. Decide whether redirects, an empty 204 response, or a particular 2xx code is acceptable for your endpoint. When an error body contains a request identifier or useful server message, capture it before throwing, while avoiding the accidental logging of credentials or personal data.
How do I add a timeout to fetch()?
Use AbortSignal.timeout(milliseconds) to create a signal that aborts automatically after the specified interval. Pass that signal in the request options. The timeout is an abort deadline, not a promise that transforms every failure into an HTTP error.
async function fetchWithTimeout(url, init = {}, timeoutMs = 10_000) {
const signal = AbortSignal.timeout(timeoutMs);
return fetch(url, { ...init, signal });
}
const response = await fetchWithTimeout('/api/report', {}, 8_000);A timeout signal starts when it is created. Create a new one for every attempt; reusing an already elapsed signal makes subsequent attempts fail immediately. In browser fetch, the platform does not expose a portable “connect timeout” setting. A signal can bound the overall activity associated with that attempt, while the promise returned by fetch() specifically fulfills when headers are available.
If you read a body after headers arrive, keep using the same signal. Aborting at that stage can cause response.text(), response.json(), or another body reader to reject with an AbortError. If your definition of a deadline includes parsing, start the timeout before the request and do not consider the operation complete until the body has been consumed.
How do I support both a timeout and user cancellation?
Compose the caller’s signal with a per-attempt timeout. AbortSignal.any() creates a signal that aborts when either input signal aborts, so a user navigating away can stop the request before the deadline while a stalled request still ends automatically.
Rank #2
- 5-in-1 USB-C Hub: Experience comprehensive connectivity featuring a Power Delivery input, two USB-A 2.0 ports, a USB-A 3.0 port, and an HDMI port. (Note: The USB-C power delivery input port is only for connecting an external wall charger to power your laptop and cannot power peripheral devices.)
- 90W Pass-Through Charging: Achieve optimal charging with 90W pass-through power to your laptop, supported by a total input of 100W, with the hub reserving 10W for operational efficiency. (Note: Wall charger not included.)
- Quick Data Transfers: Accelerate your productivity with rapid data transfers using a high-speed 5Gbps USB 3.0 port and two 480Mbps USB 2.0 ports.
- 4K HDMI Display: Enhance your visual experience with a hub capable of delivering 4K resolution at 30Hz in both mirror and extend modes. Please note that this hub is compatible with MacBook (macOS 12 and newer), Windows 10 and 11, ChromeOS, and laptops equipped with DP Alt Mode and Power Delivery. Note: This device is not compatible with Linux.
- What You Get: Anker USB-C Hub (5-in-1, 4K HDMI), welcome guide, 18-month warranty, and our friendly customer service.
function signalForAttempt(callerSignal, timeoutMs) {
const timeoutSignal = AbortSignal.timeout(timeoutMs);
return callerSignal
? AbortSignal.any([callerSignal, timeoutSignal])
: timeoutSignal;
}
const controller = new AbortController();
const signal = signalForAttempt(controller.signal, 10_000);
const promise = fetch('/api/search?q=router', { signal });
// For example, call this from a Cancel button or component cleanup:
// controller.abort();When a request is aborted, the promise rejects with an AbortError in normal browser implementations. Do not retry an abort caused by the caller: the caller has explicitly said that the work is no longer wanted. A timeout-triggered abort may be retryable if the operation is safe and the overall budget still permits another attempt. Because both cases use an abort signal, retain the original caller signal and check its aborted state (or its reason where supported) so they are not confused.
Which failures should a retry policy handle?
Retry only failures that are plausibly temporary and only when repeating the operation is safe. A network exception, a timeout, or a server response explicitly indicating temporary unavailability can qualify. A malformed request, authentication failure, permission error, or a deterministic validation response normally should fail immediately.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems| Outcome | Typical treatment | Why |
|---|---|---|
| Network exception (for example, connection loss) | Retry if the operation is repeat-safe and attempts remain | The request may not have reached the server or the path may recover. |
| Timeout | Retry under the same safety and budget rules | The service or network may be temporarily slow; a deadline prevents indefinite waiting. |
| 408 Request Timeout | Usually transient, subject to endpoint semantics | The server indicates that it did not receive a complete request in time. |
| 429 Too Many Requests | Honor Retry-After; otherwise use bounded backoff |
Immediate repetition can increase throttling. |
| 500 Internal Server Error | Retry only when the service documents it as transient and the operation is safe | A 500 can represent either a temporary fault or a repeatable application bug. |
| 502, 503, or 504 | Often retryable for idempotent requests, with a cap | Gateways and unavailable services commonly recover, but not always. |
| 400, 401, 403, 404, 409, or 422 | Fail or invoke endpoint-specific handling | Repeating an unchanged request rarely fixes a client, identity, conflict, or validation problem. |
The status list is a policy choice, not a universal law. An API’s documentation may mark additional statuses as transient or require special handling for conflicts. Preserve the response status, headers, and a bounded diagnostic body so callers can make that distinction.
When is it safe to retry an HTTP method?
HTTP’s idempotency model is the starting point: repeating an idempotent request has the same intended effect as making it once. RFC 9110 identifies methods such as GET, HEAD, PUT, and DELETE as idempotent by definition, although a particular implementation can still have side effects outside the protocol’s intended semantics. A client should not automatically retry a non-idempotent method unless it has a way to know that the operation is actually repeat-safe.
| Method or operation | Default retry stance | Required safeguard |
|---|---|---|
GET, HEAD |
Generally eligible for transient failures | Still respect authorization, rate limits, and server-specific rules. |
PUT, DELETE |
Usually eligible when the endpoint follows idempotent semantics | Confirm the API’s behavior and protect against stale updates where relevant. |
POST |
Do not retry by default | Use an idempotency key or an equivalent server-side deduplication contract. |
| Any method with an external side effect | Require an explicit policy | Know whether the first attempt might have committed before the connection failed. |
A network failure does not prove that the server did nothing. For example, a payment or order creation may succeed just before the client loses its response. An idempotency key lets the server associate retries with the original operation and return the original result instead of creating a duplicate. Without such a contract, surface the uncertain outcome for confirmation rather than silently repeating it.
Rank #3
- Sleek 7-in-1 USB-C Hub: Features an HDMI port, two USB-A 3.0 ports, and a USB-C data port, each providing 5Gbps transfer speeds. It also includes a USB-C PD input port for charging up to 100W and dual SD and TF card slots, all in a compact design.
- Flawless 4K@60Hz Video with HDMI: Delivers exceptional clarity and smoothness with its 4K@60Hz HDMI port, making it ideal for high-definition presentations and entertainment. (Note: Only the HDMI port supports video projection; the USB-C port is for data transfer only.)
- Double Up on Efficiency: The two USB-A 3.0 ports and a USB-C port support a fast 5Gbps data rate, significantly boosting your transfer speeds and improving productivity.
- Fast and Reliable 85W Charging: Offers high-capacity, speedy charging for laptops up to 85W, so you spend less time tethered to an outlet and more time being productive.
- What You Get: Anker USB-C Hub (7-in-1), welcome guide, 18-month warranty, and our friendly customer service.
How should backoff, jitter, and Retry-After work?
When a server sends Retry-After, use it as the server’s requested wait. The value can be a number of seconds or an HTTP date; parse both forms and impose a client maximum so a bad or extremely long value cannot freeze the application indefinitely.
Free tools Windows power users keep installed
One-click scans. No signup required.
If the header is absent, use capped exponential backoff. A common base delay is multiplied by powers of two for successive retries, then capped at a maximum. Add jitter so many clients that failed together do not all reconnect at the same instant.
function fullJitterDelay(attempt, baseMs = 250, capMs = 8_000) {
const ceiling = Math.min(capMs, baseMs * 2 ** attempt);
return Math.floor(Math.random() * (ceiling + 1));
}
function sleep(ms, signal) {
return new Promise((resolve, reject) => {
const timer = setTimeout(resolve, ms);
if (!signal) return;
if (signal.aborted) {
clearTimeout(timer);
reject(signal.reason ?? new DOMException('Aborted', 'AbortError'));
return;
}
signal.addEventListener('abort', () => {
clearTimeout(timer);
reject(signal.reason ?? new DOMException('Aborted', 'AbortError'));
}, { once: true });
});
}Full jitter chooses a random delay between zero and the calculated ceiling. Equal jitter keeps a portion of the calculated delay and randomizes the remainder. Whichever strategy you choose, bound both the per-attempt delay and the total elapsed-time budget. Waiting must also be cancelable; otherwise a user who canceled during backoff will still be stuck until the timer expires.
How can I build one request wrapper with retries and cancellation?
The wrapper below shows the control flow. It is a design pattern: production code must implement the classification functions, parse Retry-After accurately, preserve useful diagnostics, and recreate the request body for every attempt.
async function requestWithRetry(url, init = {}, options = {}) {
const {
attempts = 3,
timeoutMs = 10_000,
signal: callerSignal,
maxElapsedMs = 30_000
} = options;
const started = performance.now();
const method = (init.method || 'GET').toUpperCase();
for (let attempt = 0; attempt < attempts; attempt++) {
if (callerSignal?.aborted) throw callerSignal.reason;
if (performance.now() - started >= maxElapsedMs) {
throw new Error('Retry time budget exceeded');
}
const signal = signalForAttempt(callerSignal, timeoutMs);
try {
// Build a fresh init/body here when the body is a stream or one-shot value.
const response = await fetch(url, { ...init, method, signal });
if (response.ok) return response;
if (!isRetryableStatus(response.status) || !isIdempotent(method)) {
throw await httpErrorWithDetails(response);
}
const retryAfter = response.headers.get('Retry-After');
const delay = retryAfter
? parseRetryAfter(retryAfter)
: fullJitterDelay(attempt);
await sleep(delay, callerSignal);
} catch (error) {
if (callerSignal?.aborted) throw error;
if (error.name === 'AbortError' && !isTimeout(error)) throw error;
if (!isRetryableError(error) || !isIdempotent(method) || attempt === attempts - 1) {
throw error;
}
await sleep(fullJitterDelay(attempt), callerSignal);
}
}
throw new Error('Request failed without a response');
}There are two important implementation details in this shape. First, a response that is retryable must be closed or otherwise handled according to the runtime so unused body data does not consume a connection indefinitely. Second, a request body may be one-shot: a consumed stream, reader, or already-used Blob cannot necessarily be sent again. Store immutable bytes, a string, or a factory that creates a fresh body and matching headers for each attempt.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Rank #4
- Dual Converters, Infinite Potential：Includes 2× USB C male to USB A female adapters and 2× USB A male to USB C female adapters. Perfect for a wide range of uses—tablets with Bluetooth keyboards, expand USB ports on macbook, and more. Two different converters for all your daily needs
- Next-Level 10Gbps & 3A Charging: No more slow 480Mbps, this usb to usb c adapter has a transfer speed of up to 10Gbps, allowing you to do more transferring in less time. This usb adapter fits both USB A and USB C charger, supporting up to 3A fast charging
- Upgraded Exquisite Craftsmanship: With an aluminum alloy housing and metal connector, the usbc to usb adapter is extremely durable and sturdy. Rigorously tested to withstand more than 10,000 times of plugging and unplugging, ensuring long-lasting performance
- Broad Compatible: The usb c to usb adapter widely supports all USB C/ USB A devices like laptops, tablets, cellphones, car chargers, and phone chargers. Such as compatible with MacBook Pro/Air 2023/2022, Thunderbolt 4/3 Devices,Apple MagSafe Watch 9/8/7/SE/Ultra, iPad Pro 2022/2021, Samsung Galaxy S23/S20/S10, and iPhone 17/16/15 Pro. Plug and play
- Please Note: To reach 10Gbps speed, keep the cable under 3.3 ft. For USB A Male to USB C adapters, try flipping the USB C connector. USB C Male to USB A adapters support bidirectional 10Gbps transfer within 3.3 ft
How do I choose attempts, timeouts, and an overall budget?
Set values from the user-visible operation rather than choosing a universal number. A search-as-you-type request may have a short deadline and only one retry, while a background synchronization job can tolerate a longer budget. The attempt count limits how many network operations occur; the elapsed-time budget limits the combined request, body reading, and waits.
- Make the per-attempt timeout shorter than the user’s tolerance for the operation.
- Reserve time for backoff; three ten-second attempts plus waits can exceed a thirty-second budget.
- Use fewer retries for interactive actions and more conservative retrying for rate-limited services.
- Stop when the caller’s signal aborts, even if the wrapper is waiting between attempts.
Do not claim that a retry policy guarantees success. It only converts some transient failures into a later attempt while placing a finite bound on extra load and user delay.
What should a reliable wrapper record for diagnosis?
Record structured, privacy-conscious events for each attempt: operation name, method, host or route, attempt number, elapsed time, timeout setting, outcome category, status code, selected response headers, and whether the caller canceled. A correlation or request ID returned by the service is especially useful when a timeout occurs after the server may have committed the operation.
Never log authorization headers, cookies, full URLs containing secrets, or unrestricted response bodies. Distinguish a caller abort from a timeout in metrics, because one indicates normal user control while the other may indicate capacity or dependency problems. Track retry-after delays and exhausted budgets so a high retry rate does not hide a failing upstream service.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What browser and runtime details can break this design?
- Signal API support: current browsers and modern JavaScript runtimes provide
AbortControllerand commonly provideAbortSignal.timeout()andAbortSignal.any(); verify the minimum versions your application supports and provide a small compatibility helper when necessary. - Body consumption: once a response body is read, it cannot normally be read again unless you clone it first. Decide whether diagnostics or application parsing gets the stream.
- Credentials and CORS: a retry does not bypass cross-origin policy or authentication requirements. A failed preflight or a rejected credential should not be treated as a transient 503.
- Service workers and proxies: an intermediary may retry or cache requests independently. Coordinate headers and idempotency behavior so layers do not multiply attempts.
- Clock and timer limits: very long delays can exceed timer limits or the page’s lifecycle. Persist background work in a suitable queue rather than relying on a sleeping page.
How should I test timeout, retry, and cancellation behavior?
Use a controllable test server or mock transport, not only a successful local endpoint. Exercise each branch deliberately:
Best Value
- 5-in-1 Connectivity: Equipped with a 4K HDMI port, a 5 Gbps USB-C data port, two 5 Gbps USB-A ports, and a USB C 100W PD-IN port. Note: The USB C 100W PD-IN port supports only charging and does not support data transfer devices such as headphones or speakers.
- Powerful Pass-Through Charging: Supports up to 85W pass-through charging so you can power up your laptop while you use the hub. Note: Pass-through charging requires a charger (not included). Note: To achieve full power for iPad, we recommend using a 45W wall charger.
- Transfer Files in Seconds: Move files to and from your laptop at speeds of up to 5 Gbps via the USB-C and USB-A data ports. Note: The USB C 5Gbps Data port does not support video output.
- HD Display: Connect to the HDMI port to stream or mirror content to an external monitor in resolutions of up to 4K@30Hz. Note: The USB-C ports do not support video output.
- What You Get: Anker 332 USB-C Hub (5-in-1), welcome guide, our worry-free 18-month warranty, and friendly customer service.
- Delay connection or headers beyond the deadline and verify that the attempt ends.
- Send a 503 followed by a 200 and confirm the second request waits according to the policy.
- Send a 404 and verify that no retry occurs and the status remains available to the caller.
- Abort before the request, during header wait, during body reading, and while backoff is sleeping.
- Drop the connection after the server records a write, then verify that non-idempotent work is not duplicated.
- Use a replayable and a non-replayable body to ensure the wrapper refuses unsafe retries.
- Return malformed, past, and very large
Retry-Aftervalues and check that parsing is bounded.
Assertions should cover both the externally visible error and the number, timing, and method of attempts. This catches accidental retries of validation errors and hidden waits that make cancellation appear broken.
What are the most common implementation mistakes?
- Using only
response.ok: this loses status-specific policy and useful error details. Classify the status before parsing. - Racing a timeout promise without aborting fetch: the caller may see a timeout while the underlying request continues consuming resources. Abort the actual fetch signal.
- Retrying every exception: programmer errors, bad URLs, authentication failures, and caller cancellation are not transient network faults.
- Retrying
POSTautomatically: a lost response can mean the first side effect succeeded. Require an idempotency mechanism. - Ignoring
Retry-After: immediate retries can worsen throttling and violate the service’s pacing instruction. - Reusing one timeout signal: after it aborts, every later attempt fails instantly. Construct a fresh signal in the loop.
- Sleeping without a signal: cancellation during backoff becomes ineffective. Make the delay itself abortable.
- Reusing a consumed body: the second attempt may send an empty or invalid payload. Recreate the body or disable retries.
Frequently Asked Questions
Does a fetch timeout mean the server did not receive my request?
No. The client can time out after the server received and processed the request but before the response arrived. For operations with side effects, use an idempotency key or reconcile the operation by querying its status instead of blindly sending it again.
Can I retry a request after the browser goes offline?
You can classify a network exception as retryable, but first check whether the operation is still relevant and whether connectivity has returned. Listen for application-level online or connectivity signals only as hints; the actual request remains the authority.
Should retries happen in the browser or on the server?
Either layer may retry, but define ownership clearly. If both layers retry the same call, attempts multiply and can overwhelm the upstream service; pass an idempotency key and a shared deadline when retries span layers.
How do I preserve an error response body for the caller?
Read it once, preferably with a size limit and a content-type check, then attach the parsed or text-limited value to a custom error containing status and headers. Do not attempt to read the same body stream again unless you cloned the response first.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
