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

[PR #6591] [CLOSED] Fix sync error when applying rules with invalid actions #64607

New Issue
Closed
opened 2026-05-11 21:44:47 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-05-11 21:44:47 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/actualbudget/actual/pull/6591
Author: @Copilot
Created: 1/7/2026
Status: ❌ Closed

Base: master ← Head: copilot/fix-synchronisation-error

📝 Commits (4)

  • ad81838 Initial plan
  • 2a29655 Add release notes for PR #6591
  • 8fd23cf Fix null handling in rule-apply-actions to prevent sync errors
  • 07a1b72 Fix spelling: synchronisation -> synchronization

📊 Changes

2 files changed (+39 additions, -6 deletions)

View changed files

📝 packages/desktop-client/src/components/rules/RuleEditor.tsx (+33 -6)
➕ upcoming-release-notes/6591.md (+6 -0)

📄 Description

Fix synchronization error upon rule application

Original Problem (Fixed)

When updating a rule by adding more strings to match in the "note" field and applying it to matched transactions, a synchronization error occurs. The error message is: "We had problems syncing your changes."

Root Cause: The rule-apply-actions handler can return null when there's a parsing error in the actions. The frontend code didn't handle this null case and tried to call .errors.forEach() on null, which threw an error that propagated up and triggered a sync error notification.

Solution: Added proper null checking and error handling in RuleEditor.tsx.

Multi-Tab Issue (Architectural Limitation)

The comment requested investigation into why multiple browser tabs break sync.

Finding: This is a fundamental limitation of the browser storage architecture:

  • Actual uses absurd-sql with IndexedDBBackend for SQLite persistence in browsers
  • IndexedDB can only be safely written to by one connection at a time
  • When a second tab attempts to write, the backend triggers a fallback-write-error to prevent data corruption
  • The app already detects this scenario and shows a warning (see global-events.ts line 108-122)

Potential Solutions (all require significant architectural changes):

  1. Tab synchronization via BroadcastChannel/SharedWorker
  2. Leader election to designate one tab as write-master
  3. Read-only mode for secondary tabs with real-time updates
  4. LocalStorage lock to prevent multiple tabs

This is a separate architectural issue beyond the scope of the original bug fix.

Changes Made

  • Fixed null handling in rule-apply-actions (commit 8fd23cf)
  • Fixed spelling in release notes (commit 07a1b72)
  • Investigated and documented multi-tab limitation
  • All tests passing
  • Security scan passed
Original prompt

This section details on the original issue you should resolve

<issue_title>[Bug]: syncronisation error upon rule application</issue_title>
<issue_description>### Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

every time i update a rule by adding one more strring to match in field "note" upon apply on matched transaction i get this error message

Image Image

How can we reproduce the issue?

every time i update a rule by adding one more strring to match in field "note" upon apply on matched transaction i get the error message

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome

Operating System

Mac OSX</issue_description>

Comments on the Issue (you are @copilot in this section)

@youngcw My guess is that this isn't because of rules but because you are having syncing problems in general. Make sure your server is accessible by your client. @youngcw Having 2 browser tabs open breaks syncing in general, its a known issue.

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/actualbudget/actual/pull/6591 **Author:** [@Copilot](https://github.com/apps/copilot-swe-agent) **Created:** 1/7/2026 **Status:** ❌ Closed **Base:** `master` ← **Head:** `copilot/fix-synchronisation-error` --- ### 📝 Commits (4) - [`ad81838`](https://github.com/actualbudget/actual/commit/ad818383ab67947039195821b491f99f1581a436) Initial plan - [`2a29655`](https://github.com/actualbudget/actual/commit/2a2965597151f7764879f3efcd96354f1c76da4f) Add release notes for PR #6591 - [`8fd23cf`](https://github.com/actualbudget/actual/commit/8fd23cfd92479591373047b89c86a3e61c7e4113) Fix null handling in rule-apply-actions to prevent sync errors - [`07a1b72`](https://github.com/actualbudget/actual/commit/07a1b72a924e56867b7169622b548290a1567429) Fix spelling: synchronisation -> synchronization ### 📊 Changes **2 files changed** (+39 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `packages/desktop-client/src/components/rules/RuleEditor.tsx` (+33 -6) ➕ `upcoming-release-notes/6591.md` (+6 -0) </details> ### 📄 Description ## Fix synchronization error upon rule application ### Original Problem (Fixed) When updating a rule by adding more strings to match in the "note" field and applying it to matched transactions, a synchronization error occurs. The error message is: "We had problems syncing your changes." **Root Cause**: The `rule-apply-actions` handler can return `null` when there's a parsing error in the actions. The frontend code didn't handle this null case and tried to call `.errors.forEach()` on null, which threw an error that propagated up and triggered a sync error notification. **Solution**: Added proper null checking and error handling in `RuleEditor.tsx`. --- ### Multi-Tab Issue (Architectural Limitation) The comment requested investigation into why multiple browser tabs break sync. **Finding**: This is a fundamental limitation of the browser storage architecture: - Actual uses `absurd-sql` with `IndexedDBBackend` for SQLite persistence in browsers - IndexedDB can only be safely written to by one connection at a time - When a second tab attempts to write, the backend triggers a `fallback-write-error` to prevent data corruption - The app already detects this scenario and shows a warning (see `global-events.ts` line 108-122) **Potential Solutions** (all require significant architectural changes): 1. Tab synchronization via BroadcastChannel/SharedWorker 2. Leader election to designate one tab as write-master 3. Read-only mode for secondary tabs with real-time updates 4. LocalStorage lock to prevent multiple tabs This is a separate architectural issue beyond the scope of the original bug fix. --- ### Changes Made - [x] Fixed null handling in `rule-apply-actions` (commit 8fd23cf) - [x] Fixed spelling in release notes (commit 07a1b72) - [x] Investigated and documented multi-tab limitation - [x] All tests passing - [x] Security scan passed <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>[Bug]: syncronisation error upon rule application</issue_title> > <issue_description>### Verified issue does not already exist? > > - [x] I have searched and found no existing issue > > ### What happened? > > every time i update a rule by adding one more strring to match in field "note" upon apply on matched transaction i get this error message > > <img width="946" height="222" alt="Image" src="https://github.com/user-attachments/assets/59da1390-dd36-4f79-90d5-be6a7749a60c" /> > > <img width="607" height="138" alt="Image" src="https://github.com/user-attachments/assets/6cad916a-32c6-4390-af0c-73492969aad6" /> > > ### How can we reproduce the issue? > > every time i update a rule by adding one more strring to match in field "note" upon apply on matched transaction i get the error message > > > > ### Where are you hosting Actual? > > Docker > > ### What browsers are you seeing the problem on? > > Chrome > > ### Operating System > > Mac OSX</issue_description> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > <comment_new><author>@youngcw</author><body> > My guess is that this isn't because of rules but because you are having syncing problems in general. Make sure your server is accessible by your client. </body></comment_new> > <comment_new><author>@youngcw</author><body> > Having 2 browser tabs open breaks syncing in general, its a known issue.</body></comment_new> > </comments> > </details> <!-- START COPILOT CODING AGENT SUFFIX --> - Fixes actualbudget/actual#6556 <!-- START COPILOT CODING AGENT TIPS --> --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-05-11 21:44:47 -05:00
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 pull-request
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#64607
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?