Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Mobile startup network failures sign users out and delete pending recording files

Ouverte
#3,315 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@AksharP5 y travaille déjà.

Depuis le 26/10/2026.

  • #3316 par @AksharP5 — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
react-native, typescript

Piste de recherche

Read apps/mobile/src/auth/AuthContext.tsx and its automatic bootstrap rejection handler, then trace how apps/mobile/src/uploads/recording-upload-provider.tsx handles signedOut. Start by running the described AuthProvider and RecordingUploadProvider fixture for network errors, HTTP 503, and HTTP 401. Done means temporary failures preserve credentials and recording recovery files while HTTP 401 still signs the user out; pull-to-refresh should remain able to retry bootstrap.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Description

Launching the mobile app with a saved session during a temporary network outage signs the user out and deletes pending recording recovery data. The same happens when the bootstrap endpoint returns HTTP 503 or 429.

The automatic bootstrap failure handler clears the API key and user ID for every error. RecordingUploadProvider then sees signedOut, empties its queue, and calls FileSystem.deleteAsync for the recording directories and recording-upload-queue.json.

A transport or temporary service error should retain the session and recovery files. A server rejection of the credentials with HTTP 401 should still clear the session.

Reproduction
  1. Sign in to the mobile app and leave a camera recording awaiting upload completion.
  2. Relaunch with the saved session while the bootstrap request cannot reach the network, or responds with HTTP 503.
  3. The app returns to sign-in and deletes the pending recording directory and saved retry queue.

Reproduced against 5fcf8e9cb42625443d31be1023cc816284a7caf5 by mounting the actual AuthProvider and RecordingUploadProvider, using the real MobileApiClient with HTTP and native storage fixtures. In both network-error and HTTP 503 cases, the baseline called deletion for file:///documents/cap_123 and file:///documents/recording-upload-queue.json. HTTP 401 retained its expected sign-out behavior.

Additional Context
  • Affected code: apps/mobile/src/auth/AuthContext.tsx, automatic bootstrap rejection handler; downstream cleanup in apps/mobile/src/uploads/recording-upload-provider.tsx.
  • Environment: current mobile app source, Bun 1.4.4, Node 24.22.1, Vitest with native module and HTTP fixtures. No physical iOS device verification.
  • Existing pull-to-refresh can retry bootstrap after connectivity returns. The credentials should remain available for that retry.
Langage dominant
Rust
Étoiles
23.7k
Forks
2.1k
Merge moyen
1 j 6 h
PR mergées (30 j)
705

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de CapSoftware/Cap

Toutes les issues de CapSoftware/Cap

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.