Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#44 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
bun, javascript, localization, typescript
Domain
database, frontend, testing

Research direction

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.

Written by the indexing model from the issue text.

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.

Dominant language
Python
Stars
2
Forks
4
Avg merge
6h 54m
Merged PRs (30d)
7

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from QMeshPy/distributed-quantum

All issues in QMeshPy/distributed-quantum

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.