Motivation & Problem
In lib/core/storage/local_db.dart, _open() currently performs:
Future<Database> _open() async {
if (_db != null && _db!.isOpen) return _db!;
await initFfi();
...
_db = await databaseFactoryFfi.openDatabase(...);
return _db!;
}
When multiple operations query LocalDb simultaneously on cold startup (e.g. AppSettings.getTheme(), LocalDb.listConnections(), and LocalDb.listFolders()), all parallel callers can enter _open() before the first openDatabase() finishes. This can lead to multiple concurrent SQLite open attempts on the same file path before _db is assigned.
Proposed Scope
- In LocalDb:
- Introduce a single-flight memoization mechanism (e.g. Future<Database>? _openFuture) to guarantee that concurrent callers share the exact same opening Future.
- Clear _openFuture on close() or if database opening throws an error.
- Add unit tests in local_db_test.dart verifying that concurrent simultaneous calls to _open() / database operations safely complete with a single open handle.
Acceptance Criteria
- Parallel concurrent invocations of LocalDb._open() are safely deduplicated (single-flight).
- Database handle lifecycle is cleanly reset on LocalDb.instance.close().
- All database tests pass reliably.
Reactions are currently unavailable
Motivation & Problem
In lib/core/storage/local_db.dart, _open() currently performs:
When multiple operations query LocalDb simultaneously on cold startup (e.g. AppSettings.getTheme(), LocalDb.listConnections(), and LocalDb.listFolders()), all parallel callers can enter _open() before the first openDatabase() finishes. This can lead to multiple concurrent SQLite open attempts on the same file path before _db is assigned.
Proposed Scope
Acceptance Criteria