Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#44 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
bun, javascript, localization, typescript
Bereich
database, frontend, testing

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Python
Sterne
2
Forks
4
Ø Merge
6 Std. 54 Min.
Gemergte PRs (30 T.)
7

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus QMeshPy/distributed-quantum

Alle Issues in QMeshPy/distributed-quantum

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.