Harden taskflow: persistence, consistent error handling, and input validation
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start with docs/architecture.md, README.md, and the existing TaskStore, API, CLI, and happy-path tests to map the current boundaries. Decide the persistence approach and one error contract before implementation. Done means restart-safe tasks, validated titles and ids, consistent behavior across store/API/CLI, expanded tests, and updated documentation.
Written by the indexing model from the issue text.
Description
taskflow currently works in-memory only and behaves inconsistently at its boundaries. docs/architecture.md documents the known gaps. We want to close them properly rather than patching symptoms.
Goals
- Persistence —
TaskStoreis memory-only, so every restart loses all tasks. Add a durable backing store behind the existingTaskStoreinterface so the API and CLI are unaffected. - Consistent error semantics —
getraisesTaskNotFoundbutdeletesilently succeeds on a missing id, andcompletedoes not catchTaskNotFoundat all, so it surfaces an unhandled exception through the API. Pick one contract and apply it uniformly across store, API, and CLI. - Input validation — there is no validation on task titles or ids. Empty titles are accepted and arbitrary id strings are trusted on lookup.
- Test coverage — the current tests cover the happy paths only. The gaps above are untested.
- Docs —
README.mdanddocs/architecture.mddescribe the current limitations and will be wrong once the above lands.
Constraints
- Keep the public
TaskStoreAPI stable where practical; call out any unavoidable break. - The CLI must keep working end to end.
Please plan this properly before any implementation.
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bradygaster/squad-e4-validation
-
squad squad:docs
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
squad squad:tester
Difficulty 3/5 1-2 days Newbie friendliness 66/100
-
squad squad:backend
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
squad squad:backend
Difficulty 4/5 3-5 days Newbie friendliness 65/100
-
squad squad:backend
Difficulty 4/5 3-5 days Newbie friendliness 55/100
All issues in bradygaster/squad-e4-validation
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
GoogleCloudPlatform/gce-rescue#195 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
intake mcp-intake needs-ac needs-human-review priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Ikalus1988/MisakaNet#3848 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
521xueweihan/HelloGitHub#4105 ·
-
bug size:XS
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day