Loading, Errors and Retry

A server request takes time and can fail. Show a loading state, explain failures, and let users retry. A failed request should not be presented as a successful empty report.

Try a failed request

Interactive example

Recover from a connection failure

This simulated backend can fail a request without clearing your last successful table.

Try it: Simulate connection failure, then choose Retry.

The example loads when visible.

Reset

What to notice: The old report stays visible during failure; retry loads sales by product.

This example uses a simulated backend. Trigger a failure, inspect the message, then retry. It demonstrates the client request lifecycle, not a deployed service or a database implementation.

Keep one request owner

The HTTP store or adapter receives the request’s cancellation signal. Pass it to your transport so a replaced report or closed view can cancel unnecessary work.

import type { PivotLoadRequest, PivotLoadResponse } from '@revolist/pivot';

async function load(request: PivotLoadRequest, signal?: AbortSignal): Promise<PivotLoadResponse> {
  const response = await fetch('/api/pivot/load', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(request),
    signal,
  });
  if (!response.ok) throw new Error('Could not load the sales report.');
  return response.json();
}

This is a transport outline; a production endpoint must return the validated Pivot response, enforce access, and perform the requested calculations.

Give a useful recovery action

Situation	Explain and offer
Network or temporary service failure	Retry the current report
Expired session or denied access	Sign in or request access; do not silently fall back to local data
Unsupported measure or query	Choose a supported field/operation
Report or export exceeds a limit	Reduce the scope or use an approved backend workflow
A newer report replaces the request	Discard the stale result

Read retries and freshness are configured through caching and refresh. Explicit application actions remain separate from write retries. Respect the last accepted result, and tell users when it is being retained while the requested replacement has failed.

Next steps

Request and response contracts, cache freshness, limits and recovery, and chart loading/error handling.