GothenburgBitFactory / GothenburgBitFactory/taskchampion
Add tests for manually manipulated DB
- Dominant language
- Rust
- Stars
- 184
- Forks
- 41
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 7
Description
In https://github.com/GothenburgBitFactory/taskwarrior/issues/3530 @snaka224 mentioned they edited the DB. They probably aren't the first or only person to do so!
The result is a "corrupted" DB in the sense that an [invariant](https://gothenburgbitfactory.org/taskchampion/sync-model.html#replica-invariant) is invalidated: the cumulative effects of the ops in the `operations` table are not the same as the `tasks` table.
Let's add some tests for that circumstance to ensure that at least the "blast radius" of this corruption is limited.
* TC does not panic or crash
* Sync continues to run successfully
* Only the modified task is affected locally
* After sync, only the modified task is different between replicas
This would be a good first task since it just requires writing some tests. If bugs are found, we can file and fix those separately. The resulting tests are probably a mix of unit-style tests (such as for `apply` when an Update operation is applied to a task that has been deleted) and integration tests (for things that involve running `sync`). There are already some example integration tests in `taskchampion/tests`.
Contributor guide
Research direction
Start with the existing integration tests in taskchampion/tests and the apply path for an Update operation applied to a deleted task. Add unit and sync-focused tests covering manually edited database state. Done means TC does not panic, sync succeeds, only the modified task is locally affected, and replicas differ only for that task after sync.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- databases, distributed-systems, testing
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100