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

[GH-ISSUE #2877] [Bug]: Deduplication not handling gocardless inconsistencies after #2770 #15385

New Issue
Closed
opened 2026-04-14 18:21:26 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-14 18:21:26 -05:00
Owner
Copy Link

Originally created by @matt-fidd on GitHub (Jun 13, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/2877

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

Firstly, I believe that #2770 was a sensible change, if two imported transactions have completely distinct IDs provided then they should be treated as separate transactions.

Unfortunately it seems that GoCardless have very inconsistent implementations and it is very common (at least with my accounts) that the financial_id (or imported_id) changes when a transaction is booked. #2770 breaks deduplication when this happens.

I've reported these issues to gocardless too as I believe that it's not the expected behaviour, however this was handled quite gracefully by actual before this change.

Below is a screenshot of the same transaction, the bottom pending and the top booked.
image

Where are you hosting Actual?

Locally via Yarn

Originally created by @matt-fidd on GitHub (Jun 13, 2024). Original GitHub issue: https://github.com/actualbudget/actual/issues/2877 ### Verified issue does not already exist? - [X] I have searched and found no existing issue ### What happened? Firstly, I believe that #2770 was a sensible change, if two imported transactions have completely distinct IDs provided then they should be treated as separate transactions. Unfortunately it seems that GoCardless have very inconsistent implementations and it is very common (at least with my accounts) that the financial_id (or imported_id) changes when a transaction is booked. #2770 breaks deduplication when this happens. I've reported these issues to gocardless too as I believe that it's not the expected behaviour, however this was handled quite gracefully by actual before this change. Below is a screenshot of the same transaction, the bottom pending and the top booked. ![image](https://github.com/actualbudget/actual/assets/81489167/1be9dab8-74a0-4e24-8a9c-e6a8b9538c21) ### Where are you hosting Actual? Locally via Yarn
GiteaMirror added the bug label 2026-04-14 18:21:26 -05:00
GiteaMirror commented 2026-04-14 18:21:30 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Jun 16, 2024):

👋 This is a good catch! GoCardless has in fact been quite loose in the "imported_id" fields.

I'm now considering to revert #2770 until we figure out a better solution.

cc @strazto maybe you have some ideas.

<!-- gh-comment-id:2171670918 --> @MatissJanis commented on GitHub (Jun 16, 2024): 👋 This is a good catch! GoCardless has in fact been quite loose in the "imported_id" fields. I'm now considering to revert #2770 until we figure out a better solution. cc @strazto maybe you have some ideas.
GiteaMirror commented 2026-04-14 18:21:30 -05:00
Author
Owner
Copy Link

@strazto commented on GitHub (Jun 17, 2024):

That's ugly on GoCardless's end

We could possibly make the behaviour introduced in #2770 optional and control it with a setting (though I don't love the added complexity)

Or revert #2770 with a TODO re. The gocardless bug, however, I don't know how fast gocardless tends to be with addressing tickets, especially when there's not much business case

Also I assume gocardless ingests various institutions' APIs to a common data model, and the behaviour may vary institute to institution, meaning that the fix may be more niche (who knows)

I don't really mind if this gets reverted, as long as I have a build I can use for my instance that includes #2770

<!-- gh-comment-id:2172183204 --> @strazto commented on GitHub (Jun 17, 2024): That's ugly on GoCardless's end We could possibly make the behaviour introduced in #2770 optional and control it with a setting (though I don't love the added complexity) Or revert #2770 with a TODO re. The gocardless bug, however, I don't know how fast gocardless tends to be with addressing tickets, especially when there's not much business case Also I assume gocardless ingests various institutions' APIs to a common data model, and the behaviour may vary institute to institution, meaning that the fix may be more niche (who knows) I don't really mind if this gets reverted, as long as I have a build I can use for my instance that includes #2770
GiteaMirror commented 2026-04-14 18:21:31 -05:00
Author
Owner
Copy Link

@Kidglove57 commented on GitHub (Jun 18, 2024):

For corroboration only.

I have three UK accounts with GoCardless. Starling, Halifax and Amex.

All three continue to sync correctly in 24.6.0 EXCEPT when I use the “edge” version whereupon Amex imports duplicate transactions, as transactions move from pending to settled.

<!-- gh-comment-id:2175381163 --> @Kidglove57 commented on GitHub (Jun 18, 2024): For corroboration only. I have three UK accounts with GoCardless. Starling, Halifax and Amex. All three continue to sync correctly in 24.6.0 EXCEPT when I use the “edge” version whereupon Amex imports duplicate transactions, as transactions move from pending to settled.
GiteaMirror commented 2026-04-14 18:21:31 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Jun 20, 2024):

Created a revert: https://github.com/actualbudget/actual/pull/2910

This is purely to unblock the upcoming release - so we wouldn't break for a bunch of users using GoCardless. My hope is that we can re-introduce some sort of version of this change in a future release.

<!-- gh-comment-id:2181544366 --> @MatissJanis commented on GitHub (Jun 20, 2024): Created a revert: https://github.com/actualbudget/actual/pull/2910 This is purely to unblock the upcoming release - so we wouldn't break for a bunch of users using GoCardless. My hope is that we can re-introduce some sort of version of this change in a future release.
GiteaMirror commented 2026-04-14 18:21:31 -05:00
Author
Owner
Copy Link

@matt-fidd commented on GitHub (Jun 20, 2024):

Thanks @MatissJanis, one option I was thinking is to scrub the imported_id on pending gocardless transactions and then trust and save the one that comes in when it's booked. Though, there are banks whose implementation works correctly and keeps a consistent ID between states.

<!-- gh-comment-id:2181561224 --> @matt-fidd commented on GitHub (Jun 20, 2024): Thanks @MatissJanis, one option I was thinking is to scrub the imported_id on pending gocardless transactions and then trust and save the one that comes in when it's booked. Though, there are banks whose implementation works correctly and keeps a consistent ID between states.
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
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#15385
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?