Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#44 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
bun, javascript, localization, typescript
Área
database, frontend, testing

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
2
Forks
4
Merge medio
6 h 54 min
PR fusionados (30 d)
7

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de QMeshPy/distributed-quantum

Todos los issues de QMeshPy/distributed-quantum

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.