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 #846] [Bug]: Import of CSV containing extra newline breaks CSV field select dropdowns #7271

New Issue
Closed
opened 2026-04-10 17:01:48 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-10 17:01:48 -05:00
Owner
Copy Link

Originally created by @zzzachzzz on GitHub (Apr 3, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/846

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

When attempting to import a csv, if the csv contains an extra blank line at the end of the file, the CSV field selector dropdowns only offer the first column as a possible selection.

To reproduce, take a valid csv to import, add a newline to the end of the file, attempt an import, and see that only the first column is offered to be selected.

image

What error did you receive?

No response

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome

Operating System

Linux

Originally created by @zzzachzzz on GitHub (Apr 3, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/846 ### Verified issue does not already exist? - [X] I have searched and found no existing issue ### What happened? When attempting to import a csv, if the csv contains an extra blank line at the end of the file, the CSV field selector dropdowns only offer the first column as a possible selection. To reproduce, take a valid csv to import, add a newline to the end of the file, attempt an import, and see that only the first column is offered to be selected. ![image](https://user-images.githubusercontent.com/14324200/229390291-7813d865-d910-4b16-883a-c5259db69c94.png) ### What error did you receive? _No response_ ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Chrome ### Operating System Linux
GiteaMirror added the bughelp wantedimporters labels 2026-04-10 17:01:48 -05:00
GiteaMirror commented 2026-04-10 17:01:49 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Apr 6, 2023):

👋 Thanks for the bug report! Would you mind providing an example CSV file showcasing the issue?

<!-- gh-comment-id:1499524171 --> @MatissJanis commented on GitHub (Apr 6, 2023): 👋 Thanks for the bug report! Would you mind providing an example CSV file showcasing the issue?
GiteaMirror commented 2026-04-10 17:01:49 -05:00
Author
Owner
Copy Link

@zzzachzzz commented on GitHub (Apr 8, 2023):

Yes, here you go. You'll find that removing the blank newline at the end of the file will fix the issue.
repro-846.csv

<!-- gh-comment-id:1500941067 --> @zzzachzzz commented on GitHub (Apr 8, 2023): Yes, here you go. You'll find that removing the blank newline at the end of the file will fix the issue. [repro-846.csv](https://github.com/actualbudget/actual/files/11183788/repro-846.csv)
GiteaMirror commented 2026-04-10 17:01:50 -05:00
Author
Owner
Copy Link

@aaroneiche commented on GitHub (Apr 18, 2023):

I can replicate the issue. I think what we're seeing here is that that CSV data is essentially invalid - because the CSV format establishes that an empty new line is the end of the data, a previous empty line is basically a row that doesn't have any delimiters.

While we can try to accommodate an extra line at the end of the file, it's much more practical (I think) to simply display a warning that the data is invalid. In fact, an error is already displayed - just perhaps not obvious enough that it can't be handled:

CSVError I'm guessing the error row shows up first because it's reverse chronological order.
<!-- gh-comment-id:1512434248 --> @aaroneiche commented on GitHub (Apr 18, 2023): I can replicate the issue. I think what we're seeing here is that that CSV data is essentially invalid - because the CSV format establishes that an empty new line is the end of the data, a previous empty line is basically a row that doesn't have any delimiters. While we can try to accommodate an extra line at the end of the file, it's much more practical (I think) to simply display a warning that the data is invalid. In fact, an error is already displayed - just perhaps not obvious enough that it can't be handled: <img width="787" alt="CSVError" src="https://user-images.githubusercontent.com/262515/232675218-1a3eea0d-bffb-42c3-a9c3-f4c2a17d5654.png"> I'm guessing the error row shows up first because it's reverse chronological order.
GiteaMirror commented 2026-04-10 17:01:50 -05:00
Author
Owner
Copy Link

@aaroneiche commented on GitHub (Apr 18, 2023):

Scratch my last - CSV data with bad rows don't exhibit the issue - only when there's a bad row before the end of the file newline. I'll look a little deeper at the cause.

<!-- gh-comment-id:1512436658 --> @aaroneiche commented on GitHub (Apr 18, 2023): Scratch my last - CSV data with bad rows don't exhibit the issue - only when there's a bad row before the end of the file newline. I'll look a little deeper at the cause.
GiteaMirror commented 2026-04-10 17:01:50 -05:00
Author
Owner
Copy Link

@aaroneiche commented on GitHub (Apr 18, 2023):

I've found what's causing the issue. This is coming from ImportTransactions, at line 456:

  let options = Object.keys(transactions[0]);
  mappings = mappings || {};

The first row is assumed to be a valid row with keys for each value. In the case of our test csv attached above, the parse row looks like this:

{
    "Transaction Date":""
}

Hence why only Transaction Date shows up as a valid key to select. The empty row is interpreted as the first field, and assigned to "Transaction Date".

I'm still only ankle-deep into the way that Actual works, but my approach at this point would be to force the parser to set all keys in every transaction object, even if the values are empty. Alternatively, the parser could return the field keys explicitly.

<!-- gh-comment-id:1513895278 --> @aaroneiche commented on GitHub (Apr 18, 2023): I've found what's causing the issue. This is coming from ImportTransactions, at line 456: ``` let options = Object.keys(transactions[0]); mappings = mappings || {}; ``` The first row is assumed to be a valid row with keys for each value. In the case of our test csv attached above, the parse row looks like this: ``` { "Transaction Date":"" } ``` Hence why only Transaction Date shows up as a valid key to select. The empty row is interpreted as the first field, and assigned to "Transaction Date". I'm still only ankle-deep into the way that Actual works, but my approach at this point would be to force the parser to set all keys in every transaction object, even if the values are empty. Alternatively, the parser could return the field keys explicitly.
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 help wanted importers
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#7271
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?