github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-06 07:01:45 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

[GH-ISSUE #5476] [Bug]: Crash when filtering by amount, then changing the filter condition #9292

New Issue
Closed
opened 2026-04-10 19:34:01 -05:00 by GiteaMirror · 9 comments
GiteaMirror commented 2026-04-10 19:34:01 -05:00
Owner
Copy Link

Originally created by @Kurokha on GitHub (Aug 4, 2025).
Original GitHub issue: https://github.com/actualbudget/actual/issues/5476

Originally assigned to: @OmXDev on GitHub.

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

When changing the filter condition on an already applied amount filter, the app crashes with a "Fatal Error". This occurs both in the transaction list and in the report editor.

Although the previously entered amount value is still displayed in the UI, it appears to not be passed to the updated filter condition. This results in the following error in the browser console:

Error: safeNumber: number is not an integer: null

This issue was observed with version v25.8.0.

App Crash Screen Stack Trace:

De@https://actual.domain.here/static/js/index.DbfBtwcv.js:58:93875 Ir@https://actual.domain.here/static/js/index.DbfBtwcv.js:58:94150 Me@https://actual.domain.here/static/js/TransactionList.BYmW0kmg.chunk.js:1:1971 Nw@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:34268 am@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:63086 Vb@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:73750 TS@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:107991 A@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:107044 $S@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:106872 O3@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:103948 X3@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:115554 R@https://actual.domain.here/static/js/index.DbfBtwcv.js:34:1605 EventHandlerNonNull*I4e/<@https://actual.domain.here/static/js/index.DbfBtwcv.js:34:1997 I4e@https://actual.domain.here/static/js/index.DbfBtwcv.js:34:3570 R4e@https://actual.domain.here/static/js/index.DbfBtwcv.js:34:3629 N4e@https://actual.domain.here/static/js/index.DbfBtwcv.js:50:53 L4e@https://actual.domain.here/static/js/index.DbfBtwcv.js:58:34963 @https://actual.domain.here/static/js/index.DbfBtwcv.js:58:34988

How can we reproduce the issue?

  1. Open the transaction list for one or all accounts.
  2. Select Filter > Amount and set a condition (e.g., "is greater than") along with a value.
  3. Apply the filter.
  4. Click on the applied filter and change the condition (e.g., to "is less than").
  5. Apply the updated filter — the app crashes.

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Firefox, Edge

Operating System

Windows 11

Originally created by @Kurokha on GitHub (Aug 4, 2025). Original GitHub issue: https://github.com/actualbudget/actual/issues/5476 Originally assigned to: @OmXDev on GitHub. ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? When changing the filter condition on an already applied amount filter, the app crashes with a "Fatal Error". This occurs both in the transaction list and in the report editor. Although the previously entered amount value is still displayed in the UI, it appears to not be passed to the updated filter condition. This results in the following error in the browser console: > Error: safeNumber: number is not an integer: null This issue was observed with version v25.8.0. App Crash Screen Stack Trace: > _De@https://actual.domain.here/static/js/index.DbfBtwcv.js:58:93875 Ir@https://actual.domain.here/static/js/index.DbfBtwcv.js:58:94150 Me@https://actual.domain.here/static/js/TransactionList.BYmW0kmg.chunk.js:1:1971 Nw@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:34268 am@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:63086 Vb@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:73750 TS@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:107991 A_@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:107044 $S@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:106872 O3@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:103948 X3@https://actual.domain.here/static/js/index.DbfBtwcv.js:57:115554 R@https://actual.domain.here/static/js/index.DbfBtwcv.js:34:1605 EventHandlerNonNull*I4e/<@https://actual.domain.here/static/js/index.DbfBtwcv.js:34:1997 I4e@https://actual.domain.here/static/js/index.DbfBtwcv.js:34:3570 R4e@https://actual.domain.here/static/js/index.DbfBtwcv.js:34:3629 N4e@https://actual.domain.here/static/js/index.DbfBtwcv.js:50:53 L4e@https://actual.domain.here/static/js/index.DbfBtwcv.js:58:34963 @https://actual.domain.here/static/js/index.DbfBtwcv.js:58:34988 ### How can we reproduce the issue? 1. Open the transaction list for one or all accounts. 2. Select Filter > Amount and set a condition (e.g., "is greater than") along with a value. 3. Apply the filter. 4. Click on the applied filter and change the condition (e.g., to "is less than"). 5. Apply the updated filter — the app crashes. ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Firefox, Edge ### Operating System Windows 11
GiteaMirror added the regressionbuggood first issue labels 2026-04-10 19:34:02 -05:00
GiteaMirror commented 2026-04-10 19:34:04 -05:00
Author
Owner
Copy Link

@MikesGlitch commented on GitHub (Aug 4, 2025):

Hey 👋

I'm unable to replicate this, do you have any other instructions?

Here's what I tried:

Image

<!-- gh-comment-id:3152050087 --> @MikesGlitch commented on GitHub (Aug 4, 2025): Hey 👋 I'm unable to replicate this, do you have any other instructions? Here's what I tried: ![Image](https://github.com/user-attachments/assets/366c31e6-9c9d-4f64-8fc7-6bfc15af0cd3)
GiteaMirror commented 2026-04-10 19:34:04 -05:00
Author
Owner
Copy Link

@Kurokha commented on GitHub (Aug 4, 2025):

Hi,

interestingly, this only happens when the formatting is set to use a comma as the decimal separator. Any setting that uses a dot works perfectly fine.

<!-- gh-comment-id:3152066417 --> @Kurokha commented on GitHub (Aug 4, 2025): Hi, interestingly, this only happens when the formatting is set to use a comma as the decimal separator. Any setting that uses a dot works perfectly fine.
GiteaMirror commented 2026-04-10 19:34:05 -05:00
Author
Owner
Copy Link

@qudwl commented on GitHub (Aug 5, 2025):

I think it should be a pretty simple fix! I'd love to work on it if possible

<!-- gh-comment-id:3155708297 --> @qudwl commented on GitHub (Aug 5, 2025): I think it should be a pretty simple fix! I'd love to work on it if possible
GiteaMirror commented 2026-04-10 19:34:06 -05:00
Author
Owner
Copy Link

@MikesGlitch commented on GitHub (Aug 5, 2025):

I think it should be a pretty simple fix! I'd love to work on it if possible

Absolutely, fire in 👍

<!-- gh-comment-id:3155768564 --> @MikesGlitch commented on GitHub (Aug 5, 2025): > I think it should be a pretty simple fix! I'd love to work on it if possible Absolutely, fire in 👍
GiteaMirror commented 2026-04-10 19:34:07 -05:00
Author
Owner
Copy Link

@OmXDev commented on GitHub (Aug 6, 2025):

Hi! 👋

I was able to reproduce this issue on main and narrowed it down to how the app parses numbers with different locale formats.

Environment:

  • Node 18
  • WSL Ubuntu 22.04 (running in browser mode)
  • Locale: de-DE and others using comma as decimal separator

Reproduction steps:

  1. Set number formatting to one that uses a comma decimal (e.g., de-DE, fr-FR) or certain grouping styles.

  2. Go to a transaction list → Filter → Amount.

  3. Set a condition (e.g., “is greater than”) and enter a value with these formats:

    • 1.000,33
    • 1’000.33
    • 1 000,33

  4. Apply the filter → the UI crashes with:

    Error: safeNumber: number is not an integer: null
at safeNumber (packages/loot-core/src/shared/util.ts:307:15)
...

Root cause:

safeNumber() receives null because the current number parsing fails for certain grouping/decimal separators (, , . , ' , space).

Proposed fix:

  • Add locale-aware or normalization-based parsing for all common formats before passing to integerToCurrency()
  • Gracefully handle null by validating input instead of throwing

If it’s okay, I’d like to work on this and prepare a PR. I’ve already prototyped a parser that handles 1.000,33, 1’000.33, 1 000,33, etc., and passes both comma- and dot-based inputs.

Let me know if anyone is actively working on this already — happy to collaborate!

<!-- gh-comment-id:3157630795 --> @OmXDev commented on GitHub (Aug 6, 2025): Hi! 👋 I was able to reproduce this issue on main and narrowed it down to how the app parses numbers with different locale formats. ### **Environment:** - Node 18 - WSL Ubuntu 22.04 (running in browser mode) - Locale: de-DE and others using comma as decimal separator ### **Reproduction steps:** 1. Set number formatting to one that uses a comma decimal (e.g., de-DE, fr-FR) or certain grouping styles. 2. Go to a transaction list → Filter → Amount. 3. Set a condition (e.g., “is greater than”) and enter a value with these formats: - 1.000,33 - 1’000.33 - 1 000,33 4. Apply the filter → the UI crashes with: ``` Error: safeNumber: number is not an integer: null at safeNumber (packages/loot-core/src/shared/util.ts:307:15) ... ``` ### **Root cause:** safeNumber() receives null because the current number parsing fails for certain grouping/decimal separators (**,** , **.** , **'** , **space**). ### **Proposed fix:** - Add locale-aware or normalization-based parsing for all common formats before passing to integerToCurrency() - Gracefully handle null by validating input instead of throwing If it’s okay, I’d like to work on this and prepare a PR. I’ve already prototyped a parser that handles 1.000,33, 1’000.33, 1 000,33, etc., and passes both comma- and dot-based inputs. Let me know if anyone is actively working on this already — happy to collaborate!
GiteaMirror commented 2026-04-10 19:34:09 -05:00
Author
Owner
Copy Link

@MikesGlitch commented on GitHub (Aug 6, 2025):

Sounds like a plan.

I think it must have been introduced by this: https://github.com/actualbudget/actual/pull/5167

Might be worth looking through if you haven't already. Feel free to assign this issue to yourself so nobody else works on it.

<!-- gh-comment-id:3158435836 --> @MikesGlitch commented on GitHub (Aug 6, 2025): Sounds like a plan. I think it must have been introduced by this: https://github.com/actualbudget/actual/pull/5167 Might be worth looking through if you haven't already. Feel free to assign this issue to yourself so nobody else works on it.
GiteaMirror commented 2026-04-10 19:34:10 -05:00
Author
Owner
Copy Link

@OmXDev commented on GitHub (Aug 6, 2025):

I’ve reproduced the issue and confirmed the root cause relates to locale-specific number parsing introduced after #5167.

I’ll work on a fix to extend safeNumber() handling for multiple formats.

Please assign this issue to me so others don’t duplicate the work.

<!-- gh-comment-id:3158575466 --> @OmXDev commented on GitHub (Aug 6, 2025): I’ve reproduced the issue and confirmed the root cause relates to locale-specific number parsing introduced after #5167. I’ll work on a fix to extend **safeNumber()** handling for multiple formats. Please **assign** this issue to me so others don’t duplicate the work.
GiteaMirror commented 2026-04-10 19:34:10 -05:00
Author
Owner
Copy Link

@OmXDev commented on GitHub (Aug 7, 2025):

✅ PR opened to fix this issue: #5515
This addresses the locale-specific number parsing problem discussed here.
Let me know if any changes or improvements are needed!

<!-- gh-comment-id:3165401507 --> @OmXDev commented on GitHub (Aug 7, 2025): **✅ PR opened to fix this issue:** [#5515](https://github.com/actualbudget/actual/pull/5515) This addresses the locale-specific number parsing problem discussed here. Let me know if any changes or improvements are needed!
GiteaMirror commented 2026-04-10 19:34:11 -05:00
Author
Owner
Copy Link

@MikesGlitch commented on GitHub (Aug 23, 2025):

Will be fixed for next release - went with solution in #5608 because of the work happening in the background for #5536

<!-- gh-comment-id:3216631700 --> @MikesGlitch commented on GitHub (Aug 23, 2025): Will be fixed for next release - went with solution in #5608 because of the work happening in the background for #5536
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
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug good first issue regression
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#9292
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?