Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Architecture] No composition root: DB/history services hand-wired per caller with inconsistent paths; session discovery triplicated

Open
  • Is something wrong?
#709 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Active
Tech stack
python, sqlite
Domain
backend, database

Research direction

Start by reading app/core/session.py, app/core/path_utils.py, and the listed call sites in app/main.py, app/ui/tui.py, and the CLI modules to map current service wiring and path discovery. Then trace DBWorker creation and the rollback journal paths in app/core/history.py. Done means the acceptance criteria pass: one storage layout and session discovery path, factory-owned workers, and a test showing undo, history export, and ledger resolve the same database files.

Written by the indexing model from the issue text.

Description

architecture enhancement ready-for-agent

Problem

1. Service graph is rebuilt ad hoc, with different paths each time. Several call sites construct DBWorker + Database + CacheManager + HistoryManager themselves, and they don't agree on where the databases live:

  • app/main.py:1128-1133 (handle_undo_command): Database(session_dir / "autosorter.db"), CacheManager(session_dir / "cache.db"), which are per-session.
  • app/ui/tui.py:7097-7100 (action_open_history): Database(get_app_dir() / "autosorter.db"), CacheManager(get_app_dir() / "cache.db"), which are global.
  • app/cli/ledger_cli.py:266-268: global again, same as the TUI. Also ledger_cli.py:172 and quarantine_cli.py:160.
  • app/ui/tui.py:1541, app/ui/tui.py:5744, app/demo.py:25 and Database itself at app/core/db.py:1863 create more DBWorker() instances.
  • AppSession.__init__ (app/core/session.py:199-205) is the canonical wiring, but most of these callers don't use it.

Each DBWorker() starts its own writer thread (app/core/db_worker.py:24-27), so "serialized writes" only holds per worker, not per database file.

2. Session/history discovery is implemented three times:

  • find_all_history_sessions in app/main.py:554-605 scans get_session_base_dir(), get_app_dir()/sessions and get_app_dir().
  • scan_abandoned_sessions_async in app/core/session.py:23-120 scans get_session_base_dir() only and opens history.db with plain stdlib sqlite3 first (session.py:64-71) before falling back to the cipher connection.
  • The rollback_journal.json location is rebuilt in app/core/history.py:676, 1297, 1636, 2084 and app/core/session.py:39.

3. Path roots are split across modules. get_app_dir() (app/config.py:70) defaults to ~/.autosorter. get_session_base_dir() (app/core/path_utils.py:333) defaults to a temp dir autosorter_sessions_<user>, unless AUTOSORTER_APP_DIR is set, in which case it uses <app_dir>/sessions. The default layout and the env-override layout are therefore structurally different.

Impact

History export from the TUI or ledger CLI may read a different autosorter.db/cache.db than the one undo/sort used. Session-scoped data can be lost on temp-dir cleanup. Any change to where data lives has to be made in 5+ places.

Proposed approach

  • Add app/core/storage_layout.py (or extend path_utils) as the single source of truth for app_dir, sessions_dir, session_dir(id), history_db(id), main_db(id|None), cache_db(...), ledger_db() and rollback_journal(id). Make the default and the env-override layouts the same.
  • Add app/core/session_catalog.py with one list_sessions(include_abandoned=...) used by main, tui, ledger_cli, history and scan_abandoned_sessions_async.
  • Add a factory, for example AppSession.open_existing(session_id) / Services.for_session(...), that owns one DBWorker per DB file and builds Database/CacheManager/HistoryManager. CLI and TUI handlers should call the factory instead of constructing services directly.

Acceptance criteria

  • No DBWorker() construction outside the factory/AppSession (grep).
  • Undo, history export and the ledger CLI resolve the same DB files for a given session id. A test asserts this.
  • One session-discovery implementation, and it never opens history DBs with stdlib sqlite3.
Dominant language
Python
Stars
1
Forks
0
Avg merge
9h 3m
Merged PRs (30d)
361

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fderuiter/sortify

All issues in fderuiter/sortify

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.