github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-16 23:26:48 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[PR #6776] [WIP] Fix sort order of imported same-day transactions #6732

New Issue
Closed
opened 2026-02-28 21:32:00 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-02-28 21:32:00 -06:00
Owner
Copy Link

Original Pull Request: https://github.com/actualbudget/actual/pull/6776

State: closed
Merged: No

Fixes #6588.

The problem was caused by the fact that imports happen really quickly, which means that the default value of sort_order (milliseconds timestamp) usually ends up being the same for most of the imported transactions. We then fallback to sorting by id, which is just a UUID, so the order does not reflect the order that the transactions were added in.

This PR makes it so that we explicitly set sort_order when adding/importing transactions. This has the added benefit of allowing us to keep the Promise.all. I was debating an alternate solution where we fallback to sorting by rowid instead of id, but there were some downsides:

  • If rowid is not explicitly defined on the table, the values of the entire rowid column can change when running a VACUUM statement
  • If using rowid, we must ensure that transactions are added in the same order we received them (i.e. not in parallel)
**Original Pull Request:** https://github.com/actualbudget/actual/pull/6776 **State:** closed **Merged:** No --- <!-- Thank you for submitting a pull request! Make sure to follow the instructions to write release notes for your PR — it should only take a minute or two: https://github.com/actualbudget/docs#writing-good-release-notes. Try running yarn generate:release-notes *before* pushing your PR for an interactive experience. --> Fixes #6588. The problem was caused by the fact that imports happen really quickly, which means that the default value of `sort_order` (milliseconds timestamp) usually ends up being the same for most of the imported transactions. We then fallback to sorting by `id`, which is just a UUID, so the order does not reflect the order that the transactions were added in. This PR makes it so that we explicitly set `sort_order` when adding/importing transactions. This has the added benefit of allowing us to keep the `Promise.all`. I was debating an alternate solution where we fallback to sorting by [`rowid`](https://www.sqlite.org/lang_createtable.html#rowid) instead of `id`, but there were some downsides: - If `rowid` is not explicitly defined on the table, the values of the entire `rowid` column can change when running a [`VACUUM`](https://sqlite.org/lang_vacuum.html) statement - If using `rowid`, we must ensure that transactions are added in the same order we received them (i.e. not in parallel)
GiteaMirror added the pull-request label 2026-02-28 21:32:00 -06:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#6732
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?