ActivityWatch / ActivityWatch/aw-server-rust
Decide bounded-staleness contract for parallel read connections
- Langage dominant
- Rust
- Étoiles
- 315
- Forks
- 96
- Merge moyen
- 2 j 21 h
- PR mergées (30 j)
- 14
Description
## 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.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Évaluation
Cette issue n'a pas encore été évaluée.