Handle retryable errors

Use this recipe when an application needs to decide whether retrying an operation may be appropriate.

dblurt exposes typed error metadata so applications can classify errors without parsing human messages.

Safety

Safety level: static for the example. Real retry logic may wrap read-only or broadcast calls, so your application must still consider side effects.

Retry does not mean safe

retryable: true means the error category looks transient, such as timeout or transport failure. It does not mean every operation is safe to repeat.

Use different policies:

Workflow	Retry posture
Read-only call	retry is usually reasonable with backoff
Static local operation builder	retry is rarely relevant
Broadcast after ambiguous network failure	do not blindly re-submit without checking chain state

Example

import { classifyError } from '@beblurt/dblurt';

try {
  await client.condenser.getDynamicGlobalProperties();
} catch (error) {
  const metadata = classifyError(error);

  if (metadata.retryable) {
    // Apply bounded retry/backoff policy here.
  }

  console.error(metadata.category, metadata.code);
}

API symbols

Validated source

Executable static source: examples/node/classify-retryable-error.cjs.

Run locally from the repository:

bash

node examples/node/classify-retryable-error.cjs

This example is included in npm run docs:check.

Handle retryable errors ​

Safety ​

Retry does not mean safe ​

Example ​