add-account makes two serialized Fava round-trips (add_account, then get_all_accounts) #53
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found in the high-effort code review of PR #46.
views_api.py:3761— afteradd_accountalready did a read+write round-trip against Fava/api/source, the endpoint callssync_single_account_from_beancount(payload.name), which callsfava.get_all_accounts()(account_sync.py:312) to fetch the entire account list just to find the single row it just wrote. Both calls are serialized behindFavaClient._write_lock.The endpoint already holds everything needed to mirror the account into libra's DB (name, currencies, target_file, metadata, derivable account_type/user_id/description). The second full-list Fava fetch is wasted work and adds Fava availability as an extra failure mode for the DB-mirror step.
Suggested fix
Mirror the account into the DB from in-process data after a successful
add_account, or havesync_single_account_from_beancountaccept the already-known account rather than re-fetchingget_all_accounts(). Low priority (not a hot path), but it's redundant I/O on a lock-serialized path.