[GH-ISSUE #846] [Bug]: Import of CSV containing extra newline breaks CSV field select dropdowns #7271

New Issue

GiteaMirror · 2026-04-10T17:01:48-05:00

GiteaMirror commented

2026-04-10 17:01:48 -05:00

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.

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 bug help wanted importers labels 2026-04-10 17:01:48 -05:00

GiteaMirror closed this issue

2026-04-10 17:01:49 -05:00

GiteaMirror commented

2026-04-10 17:01:49 -05:00

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

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

@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

@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

@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

@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:

I'm guessing the error row shows up first because it's reverse chronological order.

@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

@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.

@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

@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.

@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.