fix(vault): drain and replay the pin retry queue
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 55/100
- issue の種類
- 機能追加
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- bun, javascript, localization, typescript
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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.tscallsenqueue(...)when the audit write fails.frontend/src/features/vault-pinning/lib/sync-queue.tsstores entries undervault:pin_queueinlocalStorage; nothing reads and replays them.
Proposal
- Add
drainQueue()that replays entries against/api/vault/pinin timestamp order. - Run it on app start, on the browser
onlineevent, 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
fetchand fake timers (frontend/tests/*.test.mjsstyle, run withbun 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.
- 主要言語
- Python
- スター
- 2
- フォーク
- 4
- 平均マージ
- 6時間 54分
- マージ済み PR（30日）
- 7
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
QMeshPy/distributed-quantum のほかの issue
-
enhancement good first issue helia storage tier-1
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
QMeshPy/distributed-quantum#53 ·
メンテナーはふだん 1 日以内に返信
-
chain-integration enhancement payments research-spike tier-2
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
QMeshPy/distributed-quantum#78 ·
メンテナーはふだん 1 日以内に返信
-
chain-integration enhancement payments research-spike tier-2
難易度 3/5 1〜2日 初心者へのやさしさ 66/100
QMeshPy/distributed-quantum#77 ·
メンテナーはふだん 1 日以内に返信
-
chain-integration enhancement payments tier-2
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
QMeshPy/distributed-quantum#76 ·
メンテナーはふだん 1 日以内に返信
-
documentation good first issue kubo storage tier-1
難易度 2/5 1〜3時間 初心者へのやさしさ 42/100
QMeshPy/distributed-quantum#75 ·
メンテナーはふだん 1 日以内に返信
QMeshPy/distributed-quantum の issue をすべて見る
似ている issue
-
bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
yunaremaia/proto-drift#22 ·
-
bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
yunaremaia/memwatch#96 ·
-
bug good first issue
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
yunaremaia/ci-gate-watch#34 ·
-
bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
yunaremaia/agent-capability-attestation#64 ·
メンテナーはふだん 1 日以内に返信
-
bug good first issue
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
yunaremaia/agent-call-graph#43 ·
メンテナーはふだん 1 日以内に返信