r0k
r0k

Reputation: 11

Why Does My PATCH Request Occasionally Fail with Status Code 0

Problem Statement

I'm experiencing intermittent failures with a PATCH API request that runs every 20 seconds in a React application. The failures return status code 0 and seem to persist for a long duration once they start occurring.

I initially used TanStack Query (React Query) v4 to make API requests to a subdomain. My implementation looked like this:

export default function useIntervalPatch() {
  const currentTimeCallback = () => {
    // ... some logic

    someMutation.mutate({ ... });  // without other options
  };

  useInterval(currentTimeCallback, 20_000, [unitId, user.id]);
}
import { useEffect, useRef } from 'react';

export const useInterval = (callback: () => void, delay: number | null, deps: unknown[]) => {
  const savedCallback = useRef(callback);

  useEffect(() => {
    savedCallback.current = callback;
  }, [callback]);

  useEffect(() => {
    if (delay === null) {
      return;
    }

    const tick = () => savedCallback.current();
    const id = setInterval(tick, delay);

    return () => clearInterval(id);
  }, [delay, ...deps]);
};

Observed Failure Rates
I experimented with different HTTP methods and libraries, and here are the observed failure rates:

PATCH + React Query → 0.87% failure rate
PATCH + Fetch → 0.28% failure rate
POST + Fetch → 0.043% failure rate

Switching from PATCH to POST and replacing React Query with Fetch reduced the failure rate.

Investigation and Findings
1. Failure Pattern in Users
Through Datadog RUM (Real User Monitoring), I noticed that:
- When a user's first PATCH request fails, all subsequent PATCH requests fail for 30 minutes to 1 hour (even though they continue to be triggered every 20 seconds).
- These failures consistently return status code 0.

2. CloudFront Error Logs
Upon reviewing CloudFront error logs, I found that failed requests contained the following error type:
x_edge_detailed_result_type: "ClientCommError"

This indicates that the request never reached the API server—suggesting a client-side issue or a network-level failure.

3. Timeout & Immediate Failures
- The client is configured to abort requests that take longer than 10 seconds.
- However, many failures occurred almost instantly (within 0.5 seconds of initiation), so they are unlikely caused by the timeout setting.

---

Has anyone encountered a similar issue? Any insights or debugging recommendations would be greatly appreciated!

Upvotes: 1

Views: 24

Answers (0)

Related Questions