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

[GH-ISSUE #3353] [Bug]: Scheduled transaction preview with splits shows split error #98790

New Issue
Closed
opened 2026-05-29 11:58:28 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-05-29 11:58:28 -05:00
Owner
Copy Link

Originally created by @joel-jeremy on GitHub (Sep 3, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/3353

Verified issue does not already exist?

  • I have searched and found no existing issue
  • I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file)

What happened?

Steps to reproduce:

  1. Create a schedule with some splits
    image
    image
    image

  2. Set the schedule so that it shows up as Upcoming
    image

  3. The split error is shown even though the amounts are balanced

Where are you hosting Actual?

Fly.io

What browsers are you seeing the problem on?

Chrome, Other

Operating System

Windows 11

Originally created by @joel-jeremy on GitHub (Sep 3, 2024). Original GitHub issue: https://github.com/actualbudget/actual/issues/3353 ### Verified issue does not already exist? - [X] I have searched and found no existing issue - [X] I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file) ### What happened? Steps to reproduce: 1. Create a schedule with some splits ![image](https://github.com/user-attachments/assets/34e5dff6-2ee5-4326-82a4-98c10fcfac71) ![image](https://github.com/user-attachments/assets/c29daace-5c5b-4e67-be5c-e92f25dc4fda) ![image](https://github.com/user-attachments/assets/c6eefd33-ea94-40b6-a777-02910932bc14) 2. Set the schedule so that it shows up as Upcoming ![image](https://github.com/user-attachments/assets/4698d54f-66ec-47c0-89fb-22036f8fd531) 3. The split error is shown even though the amounts are balanced ### Where are you hosting Actual? Fly.io ### What browsers are you seeing the problem on? Chrome, Other ### Operating System Windows 11
GiteaMirror added the bug label 2026-05-29 11:58:28 -05:00
GiteaMirror commented 2026-05-29 11:58:30 -05:00
Author
Owner
Copy Link

@joel-jeremy commented on GitHub (Sep 8, 2024):

For visibility - @jfdoming

<!-- gh-comment-id:2336862752 --> @joel-jeremy commented on GitHub (Sep 8, 2024): For visibility - @jfdoming
GiteaMirror commented 2026-05-29 11:58:31 -05:00
Author
Owner
Copy Link

@jfdoming commented on GitHub (Sep 8, 2024):

For visibility - @jfdoming

Yes thanks for triaging! I took a look yesterday and was struggling to root cause. But I'll keep at it

<!-- gh-comment-id:2336865739 --> @jfdoming commented on GitHub (Sep 8, 2024): > For visibility - @jfdoming Yes thanks for triaging! I took a look yesterday and was struggling to root cause. But I'll keep at it
GiteaMirror commented 2026-05-29 11:58:32 -05:00
Author
Owner
Copy Link

@alter3d commented on GitHub (Sep 20, 2024):

If it helps with root cause, I can confirm that this also happens under the following scenarios:

  • Firefox on Ubuntu 24.04 (syncing to self-hosted AWS EC2 instance)
  • Firefox on Win10 (same sync server as above)
  • Native Windows application (same sync server as above)
  • Native Windows application (no sync server)

All running current 24.9.0 build.

<!-- gh-comment-id:2363058152 --> @alter3d commented on GitHub (Sep 20, 2024): If it helps with root cause, I can confirm that this also happens under the following scenarios: - Firefox on Ubuntu 24.04 (syncing to self-hosted AWS EC2 instance) - Firefox on Win10 (same sync server as above) - Native Windows application (same sync server as above) - Native Windows application (no sync server) All running current 24.9.0 build.
GiteaMirror commented 2026-05-29 11:58:32 -05:00
Author
Owner
Copy Link

@sjones512 commented on GitHub (Oct 9, 2024):

Noticed this today.

Windows 10
Firefox 130.0.1
Actual Budget v24.10.1

Not sure if it helps but I also noticed:
If I change the last split by 0.01 and save it, actual show an additional split in the transaction register that is not categorized, and the floating box will go away.

If I post the transaction it will go away, deleted the posted transaction brings it back.

If I add another split with "100% of remaining", which equals 0, it gets rid of the error, but I have an extra split for 0 in my transaction.

It also shows when the split scheduled transaction is collapsed:
image

Probably irrelevant that the errant transaction split doesn't obfuscate the amount.

<!-- gh-comment-id:2401366119 --> @sjones512 commented on GitHub (Oct 9, 2024): Noticed this today. Windows 10 Firefox 130.0.1 Actual Budget v24.10.1 Not sure if it helps but I also noticed: If I change the last split by 0.01 and save it, actual show an additional split in the transaction register that is not categorized, and the floating box will go away. If I post the transaction it will go away, deleted the posted transaction brings it back. If I add another split with "100% of remaining", which equals 0, it gets rid of the error, but I have an extra split for 0 in my transaction. It also shows when the split scheduled transaction is collapsed: ![image](https://github.com/user-attachments/assets/b1d38aed-82bd-4e31-9a88-b789ce078b28) Probably irrelevant that the errant transaction split doesn't obfuscate the amount.
GiteaMirror commented 2026-05-29 11:58:33 -05:00
Author
Owner
Copy Link

@sjones512 commented on GitHub (Oct 10, 2024):

@jfdoming I took a look at it and considered attempting a PR but don't feel familiar enough with the code to know I wont break things.

As a kludge it seems like you can just add update = recalculateSplit(update); to the end of the rules.ts execActions function.
rules.ts:723

I believe the root cause lies in this block of code in the rules.ts execActions function

for (const action of childActions) {
    const splitIndex = action.options?.splitIndex ?? 0;
    if (splitIndex >= update.subtransactions.length) {
      const { data, newTransaction } = addSplitTransaction(
        newTransactions,
        transaction.id,
      );
      update = recalculateSplit(newTransaction);
      data[0] = update;
      newTransactions = data;
    }
    action.exec(update.subtransactions[splitIndex]);
  }

In this block the amounts of the split subtransactions don't appear to be populated until after action.exec is called, but we are doing the recalculateSplit before that, in the loop.

I'm not very familiar with the code, but it seems wasteful to recalculateSplit on every iteration of the loop. I would think it could just be recalculated at the end after all of the subtransactions have been added.

<!-- gh-comment-id:2404090596 --> @sjones512 commented on GitHub (Oct 10, 2024): @jfdoming I took a look at it and considered attempting a PR but don't feel familiar enough with the code to know I wont break things. As a kludge it seems like you can just add `update = recalculateSplit(update);` to the end of the rules.ts `execActions` function. [rules.ts:723](https://github.com/actualbudget/actual/blob/23de23bd4e620ca73d3370c3937cf922ed0ad6eb/packages/loot-core/src/server/accounts/rules.ts#L723C1-L723C49) I believe the root cause lies in this block of code in the rules.ts `execActions` function ``` for (const action of childActions) { const splitIndex = action.options?.splitIndex ?? 0; if (splitIndex >= update.subtransactions.length) { const { data, newTransaction } = addSplitTransaction( newTransactions, transaction.id, ); update = recalculateSplit(newTransaction); data[0] = update; newTransactions = data; } action.exec(update.subtransactions[splitIndex]); } ``` In this block the amounts of the split subtransactions don't appear to be populated until after `action.exec` is called, but we are doing the `recalculateSplit` before that, in the loop. I'm not very familiar with the code, but it seems wasteful to recalculateSplit on every iteration of the loop. I would think it could just be recalculated at the end after all of the subtransactions have been added.
GiteaMirror commented 2026-05-29 11:58:33 -05:00
Author
Owner
Copy Link

@jfdoming commented on GitHub (Oct 10, 2024):

@jfdoming I took a look at it and considered attempting a PR but don't feel familiar enough with the code to know I wont break things.

As a kludge it seems like you can just add update = recalculateSplit(update); to the end of the rules.ts execActions function. rules.ts:723

I believe the root cause lies in this block of code in the rules.ts execActions function

for (const action of childActions) {
    const splitIndex = action.options?.splitIndex ?? 0;
    if (splitIndex >= update.subtransactions.length) {
      const { data, newTransaction } = addSplitTransaction(
        newTransactions,
        transaction.id,
      );
      update = recalculateSplit(newTransaction);
      data[0] = update;
      newTransactions = data;
    }
    action.exec(update.subtransactions[splitIndex]);
  }

In this block the amounts of the split subtransactions don't appear to be populated until after action.exec is called, but we are doing the recalculateSplit before that, in the loop.

I'm not very familiar with the code, but it seems wasteful to recalculateSplit on every iteration of the loop. I would think it could just be recalculated at the end after all of the subtransactions have been added.

@sjones512 Yeah sorry I dropped the ball on this one. I want to do a larger refactor to avoid these problems and add some unit tests. Are you okay to wait for that? I will get to it soon but work is killing me right now 😞

<!-- gh-comment-id:2404929910 --> @jfdoming commented on GitHub (Oct 10, 2024): > @jfdoming I took a look at it and considered attempting a PR but don't feel familiar enough with the code to know I wont break things. > > As a kludge it seems like you can just add `update = recalculateSplit(update);` to the end of the rules.ts `execActions` function. [rules.ts:723](https://github.com/actualbudget/actual/blob/23de23bd4e620ca73d3370c3937cf922ed0ad6eb/packages/loot-core/src/server/accounts/rules.ts#L723C1-L723C49) > > I believe the root cause lies in this block of code in the rules.ts `execActions` function > > ``` > for (const action of childActions) { > const splitIndex = action.options?.splitIndex ?? 0; > if (splitIndex >= update.subtransactions.length) { > const { data, newTransaction } = addSplitTransaction( > newTransactions, > transaction.id, > ); > update = recalculateSplit(newTransaction); > data[0] = update; > newTransactions = data; > } > action.exec(update.subtransactions[splitIndex]); > } > ``` > > In this block the amounts of the split subtransactions don't appear to be populated until after `action.exec` is called, but we are doing the `recalculateSplit` before that, in the loop. > > I'm not very familiar with the code, but it seems wasteful to recalculateSplit on every iteration of the loop. I would think it could just be recalculated at the end after all of the subtransactions have been added. @sjones512 Yeah sorry I dropped the ball on this one. I want to do a larger refactor to avoid these problems and add some unit tests. Are you okay to wait for that? I will get to it soon but work is killing me right now 😞
GiteaMirror commented 2026-05-29 11:58:35 -05:00
Author
Owner
Copy Link

@sjones512 commented on GitHub (Oct 10, 2024):

@sjones512 Yeah sorry I dropped the ball on this one. I want to do a larger refactor to avoid these problems and add some unit tests. Are you okay to wait for that? I will get to it soon but work is killing me right now 😞

Totally your call. It is a fairly intrusive UI bug when it happens, but I think it can be worked around by setting the last split rule as "a portion of the remainder" instead of "fixed-amount".

I'm not familiar with Actual's release process. If you think you'll be able to include the refactor in the next release, there is no reason to merge this. If not, this could be a band-aid to resolve the immediate issue, and a separate issue could be raised for the refactor.

Either way, good luck with work! 💪

<!-- gh-comment-id:2405293168 --> @sjones512 commented on GitHub (Oct 10, 2024): > @sjones512 Yeah sorry I dropped the ball on this one. I want to do a larger refactor to avoid these problems and add some unit tests. Are you okay to wait for that? I will get to it soon but work is killing me right now 😞 Totally your call. It is a fairly intrusive UI bug when it happens, but I think it can be worked around by setting the last split rule as "a portion of the remainder" instead of "fixed-amount". I'm not familiar with Actual's release process. If you think you'll be able to include the refactor in the next release, there is no reason to merge this. If not, this could be a band-aid to resolve the immediate issue, and a separate issue could be raised for the refactor. Either way, good luck with work! 💪
GiteaMirror commented 2026-05-29 11:58:37 -05:00
Author
Owner
Copy Link

@jfdoming commented on GitHub (Oct 10, 2024):

@sjones512 Yeah sorry I dropped the ball on this one. I want to do a larger refactor to avoid these problems and add some unit tests. Are you okay to wait for that? I will get to it soon but work is killing me right now 😞

Totally your call. It is a fairly intrusive UI bug when it happens, but I think it can be worked around by setting the last split rule as "a portion of the remainder" instead of "fixed-amount".

I'm not familiar with Actual's release process. If you think you'll be able to include the refactor in the next release, there is no reason to merge this. If not, this could be a band-aid to resolve the immediate issue, and a separate issue could be raised for the refactor.

Either way, good luck with work! 💪

Thanks! I'll try to get to it this weekend. Releases are cut around the 20th IIRC, and I'm a maintainer so I can force merge it 😈 jk, but I'll make sure it's the next release in some form.

<!-- gh-comment-id:2405368294 --> @jfdoming commented on GitHub (Oct 10, 2024): > > @sjones512 Yeah sorry I dropped the ball on this one. I want to do a larger refactor to avoid these problems and add some unit tests. Are you okay to wait for that? I will get to it soon but work is killing me right now 😞 > > Totally your call. It is a fairly intrusive UI bug when it happens, but I think it can be worked around by setting the last split rule as "a portion of the remainder" instead of "fixed-amount". > > I'm not familiar with Actual's release process. If you think you'll be able to include the refactor in the next release, there is no reason to merge this. If not, this could be a band-aid to resolve the immediate issue, and a separate issue could be raised for the refactor. > > Either way, good luck with work! 💪 Thanks! I'll try to get to it this weekend. Releases are cut around the 20th IIRC, and I'm a maintainer so I can force merge it 😈 jk, but I'll make sure it's the next release in some form.
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 bug
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#98790
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?