Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#44 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
55/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
bun, javascript, localization, typescript
Domínio
database, frontend, testing

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
2
Forks
4
Merge médio
6h 14min
PRs com merge (30d)
18

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Sem modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de QMeshPy/distributed-quantum

Todas as issues de QMeshPy/distributed-quantum

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.