#Errors And Retries

Planned APIs: This page documents error and recovery behavior after runtime release. commflow@0.0.2 does not provide request, SSE, RPC, or socket runtimes; see Current Release Quick Start for runnable exports.

#How To Use This Page

First determine whether a call received a valid response, then choose retry, fallback, or business-level handling. For installation, imports, Node versions, or current exports, read Troubleshooting.

#Result Categories

The error model distinguishes three outcomes:

This avoids a common confusion: HTTP 500 is not necessarily a transport error; it is still an HTTP response from the server.

#Request Error Handling

Recommended usage checks HTTP responses first, then catches real transport failures.

try {
  const response = await request.get('/users/42');

  if (!response.ok) {
    return null;
  }

  return await response.json();
} catch (error) {
  throw error;
}

Target error kinds:

#Retry Policy

More retry is not always better. Decide based on idempotency, whether the failure is temporary, and whether users can tolerate extra latency.

Minimum target configuration:

const request = createCommflowRequestClient({
  retry: 2,
  retryDelay: (attempt) => attempt * 200
});

retry is the number of extra attempts. retryDelay is the wait before the next attempt. SSE and socket use reconnect, not the request retry field.

#Hook Secondary Failure

Observer hooks such as afterResponse, onRetry, and onError should not turn an otherwise successful main request into a failure.

Only request-building hooks such as beforeRequest should block dispatch when they throw.

#Troubleshooting Entry Points