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

fix(vault): drain and replay the pin retry queue

Ouverte
#44 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

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

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
55/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
bun, javascript, localization, typescript

Piste de recherche

Read frontend/src/features/vault-pinning/lib/sync-queue.ts and frontend/src/features/vault-pinning/hooks/use-pin.ts to understand queue storage and enqueue behavior. Then inspect the pin UI and the /api/vault/pin handler to trace manual retry, startup and online triggers, and idempotent replay. Add tests in the frontend/tests/*.test.mjs style and run them with bun test; done means retries are ordered and bounded, successful entries are removed, and persistent failures appear in the UI.

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

Description

bug helia storage tier-1

Summary

Failed pin-audit writes are queued in the browser but never replayed. Add a drain that retries them safely.

Estimated size: S

Motivation

A pin can succeed at the provider while the audit write fails, leaving quota accounting wrong until someone fixes it by hand.

Current state in this repo

  • frontend/src/features/vault-pinning/hooks/use-pin.ts calls enqueue(...) when the audit write fails.
  • frontend/src/features/vault-pinning/lib/sync-queue.ts stores entries under vault:pin_queue in localStorage; nothing reads and replays them.

Proposal

  • Add drainQueue() that replays entries against /api/vault/pin in timestamp order.
  • Run it on app start, on the browser online event, and from a manual retry action in the pin UI.
  • Exponential backoff with a cap; de-duplicate by (cid, service, action) keeping the latest entry; stop after N failures and surface the entry in the UI.

Acceptance criteria

  • A failed audit write is replayed after reconnect and then removed from the queue.
  • Replaying the same entry twice does not change quota (the server write is idempotent).
  • Entries that keep failing are surfaced to the user instead of retrying forever.

Out of scope

  • Syncing the queue across devices.

Dependencies

  • None; can be picked up independently.

Testing plan

  • Unit tests with a fake fetch and fake timers (frontend/tests/*.test.mjs style, run with bun test).

Part of #43. Ground rules for the content layer: no secrets in the repo, content-layer failures must never block or discard quantum execution, and tests and docs ship with every PR.

Langage dominant
Python
Étoiles
2
Forks
4
Merge moyen
5 h 54 min
PR mergées (30 j)
24

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

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 QMeshPy/distributed-quantum

Toutes les issues de QMeshPy/distributed-quantum

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

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