Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Decide bounded-staleness contract for parallel read connections

オープン
#646 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
rust, sqlite
領域
api, backend, databases

調査の方向性

この issue は、aw-datastore/src/worker.rs における並列 read 接続の一貫性契約の設計に関するものです。まず、PR #616 の WAL 変更と現在の read/write パターンを理解してください。worker.rs ファイルのコードを確認し、並列 read に関する TODO を見つけてください。許容可能な stale の範囲(平均 1 秒未満、最悪の場合 1 分未満)と、read-your-writes が必要かどうかを判断してください。これは設計上の判断であり、実装タスクではありません。

索引モデルが issue の本文から書いたものです。

説明

Question

Is bounded read staleness acceptable for ActivityWatch read endpoints when reads are served from parallel read-only SQLite connections? If yes, what bounds should we design for?

Erik's current preference is:

  • under 1 second in the average case
  • never more than 1 minute in the worst case

Why this gates the design

WAL landed in #616, so readers no longer need to block the serial writer. The remaining fork for the parallel-read TODO in aw-datastore/src/worker.rs is consistency:

  • if bounded staleness is acceptable, reads can use a read-only pool with that freshness contract;
  • if read-your-writes is required, dispatch needs a synchronization/guard path before serving a read.

This issue is only to settle the consistency contract; implementation and benchmarking can follow separately.

主要言語
Rust
スター
317
フォーク
99
平均マージ
1日 13時間
マージ済み PR(30日)
66

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ActivityWatch/aw-server-rust のほかの issue

ActivityWatch/aw-server-rust の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。