Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Performance] QueryClient initialized with default config — no retry logic, aggressive cache invalidation, poor offline UX

Aperta
  • Qualcosa non va?
#137 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
react, tauri, typescript
Ambito
desktop, frontend, performance

Direzione di ricerca

Start by reading src/main.tsx to understand the existing QueryClient setup, then inspect App.tsx and current TanStack Query usage before choosing centralized error handling. Reproduce a failed request with network throttling, configure the requested retry and cache behavior, add the described boundary if appropriate, and verify that transient failures retry and recovered data is refreshed.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Description

The React application in src/main.tsx is wrapped with QueryClientProvider from TanStack Query, but the QueryClient is initialized with default configuration and no error handlers, retry logic, or cache strategies:

const queryClient = new QueryClient();
const container = document.getElementById("root");
const root = createRoot(container!);

root.render(
  <QueryClientProvider client={queryClient}>
    <ThemeProvider>
      <App />
    </ThemeProvider>
  </QueryClientProvider>,
);

This means:

  1. No retry logic on network failures: If an API request fails, TanStack Query will not retry automatically. A transient network error (timeout, temporary unavailability) will immediately show an error to the user instead of retrying.

  2. No error boundary: Failed API requests have no centralized error handler. Each component must manually handle errors, leading to inconsistent error UI and potential crashes.

  3. Aggressive cache invalidation: With default settings, cached data is discarded immediately, causing excessive API calls when navigating between views.

  4. No stale-while-revalidate pattern: The app doesn't leverage TanStack Query's ability to show stale data while fetching fresh data in the background.

  5. Missing mutation defaults: Form submissions and other mutations have no centralized error or success handling.

Users will experience:

  • Frequent errors on weak network connections
  • Slow performance due to redundant API calls
  • Inconsistent error handling across screens
  • Poor offline UX
Steps to Reproduce
  1. Open CommDesk on a slow or unstable network (simulate with browser DevTools throttling)
  2. Perform an API call (login, load community data, etc.)
  3. While the request is in flight, introduce a network error (disable network)
  4. Observe that the request fails immediately and shows an error to the user
  5. Re-enable network; the app does NOT retry automatically

Expected result: TanStack Query automatically retries failed requests with exponential backoff.

Actual result: Failed request shows error immediately with no retry.

Expected Behavior

QueryClient should be configured with:

  1. Default retry strategy (3 retries with exponential backoff for 5xx errors)
  2. Cache stale time (5 minutes before data is considered stale)
  3. Garbage collection time (10 minutes before unused cache is deleted)
  4. Default error handler for all queries and mutations
  5. Stale-while-revalidate behavior
Root Cause

QueryClient was initialized with defaults without considering the Tauri desktop environment, which has network instability concerns and limited bandwidth.

Proposed Fix
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { createRoot } from "react-dom/client";
import { ThemeProvider } from "./theme/provider";
import App from "./App";

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 5 * 60 * 1000, // 5 minutes
      gcTime: 10 * 60 * 1000, // 10 minutes (cache time)
      retry: (failureCount, error) => {
        // Retry on network errors and 5xx, but not on 4xx client errors
        if (failureCount > 3) return false;
        if (error instanceof Error && error.message.includes("401")) return false;
        if (error instanceof Error && error.message.includes("403")) return false;
        return true;
      },
      retryDelay: (attemptIndex) => Math.min(1000 * 2 ** attemptIndex, 30000),
    },
    mutations: {
      retry: 1,
      retryDelay: 1000,
    },
  },
});

const container = document.getElementById("root");
const root = createRoot(container!);

root.render(
  <QueryClientProvider client={queryClient}>
    <ThemeProvider>
      <App />
    </ThemeProvider>
  </QueryClientProvider>,
);

Additionally, implement a global query error boundary in App.tsx:

import { useQueryErrorResetBoundary } from "@tanstack/react-query";
import { ErrorBoundary } from "react-error-boundary";

function App() {
  const { reset } = useQueryErrorResetBoundary();
  
  return (
    <ErrorBoundary onReset={reset} fallback={<ErrorFallback />}>
      {/* App content */}
    </ErrorBoundary>
  );
}
Environment
  • File: src/main.tsx
  • Severity: Medium (poor UX on network instability, excessive API calls)
Checklist
  • I have searched existing issues and confirmed this is not a duplicate
  • I have read the Contributing.md guidelines
  • I have provided clear steps to reproduce the issue
  • I have described expected vs. actual behavior clearly
  • This issue title is clear and specific
  • This repository has been verified as NSOC on https://www.nsoc.in/projects

@NexGenStudioDev Could you please /assign this issue to me? I would like to configure TanStack Query with proper defaults and error handling under NSOC '26.

/assign

Lingua principale
TypeScript
Stelle
7
Fork
17
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di NexGenStudioDev/CommDesk

Tutte le issue di NexGenStudioDev/CommDesk

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.