[Bug]: Error: Missing migration file: 1763873568237-server-global-prefs.js #2873

New Issue

GiteaMirror · 2026-02-28T20:31:13-06:00

GiteaMirror commented

2026-02-28 20:31:13 -06:00

Originally created by @lavishtravel79 on GitHub (Jan 30, 2026).

Verified issue does not already exist?

I have searched and found no existing issue

What happened?

This morning I noticed that Actual would no longer sync with my Server. I use Docker Containers and have one for Edge on Port 4006, and one for Latest on 5006. Each instance is using it's own database, so Edge is on a different Database than Latest. Today I noticed my Latest container keeps failing with the following error:

Error: Missing migration file: 1763873568237-server-global-prefs.js

at /app/node_modules/migrate/lib/load-migrations.js:83:44

at Array.forEach (<anonymous>)

at /app/node_modules/migrate/lib/load-migrations.js:81:44

Node.js v22.21.1

/app/node_modules/migrate/lib/load-migrations.js:83

      return ignoreMissing ? null : fn(new Error('Missing migration file: ' + m.title))

The odd part is my Edge Container is working just fine, as I updated that about 2 weeks ago to test out the upcoming release. I haven't changed anything that I know of. I've rebuilt the Latest container but the issue keeps happening. I did a successful bank sync yesterday with Latest and it worked just fine, so unsure what could of changed overnight and how to resolve this error it keeps throwing.

My version shows as 26.1.0 which is what it's been on since the release earlier this month

How can we reproduce the issue?

I'm not sure how you would reproduce the issue as it's specific to my setup with the Docker Environment.

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome

Operating System

Windows 11

Originally created by @lavishtravel79 on GitHub (Jan 30, 2026). ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? This morning I noticed that Actual would no longer sync with my Server. I use Docker Containers and have one for Edge on Port 4006, and one for Latest on 5006. Each instance is using it's own database, so Edge is on a different Database than Latest. Today I noticed my Latest container keeps failing with the following error: Error: Missing migration file: 1763873568237-server-global-prefs.js at /app/node_modules/migrate/lib/load-migrations.js:83:44 at Array.forEach (<anonymous>) at /app/node_modules/migrate/lib/load-migrations.js:81:44 Node.js v22.21.1 /app/node_modules/migrate/lib/load-migrations.js:83 return ignoreMissing ? null : fn(new Error('Missing migration file: ' + m.title)) The odd part is my Edge Container is working just fine, as I updated that about 2 weeks ago to test out the upcoming release. I haven't changed anything that I know of. I've rebuilt the Latest container but the issue keeps happening. I did a successful bank sync yesterday with Latest and it worked just fine, so unsure what could of changed overnight and how to resolve this error it keeps throwing. My version shows as 26.1.0 which is what it's been on since the release earlier this month ### How can we reproduce the issue? I'm not sure how you would reproduce the issue as it's specific to my setup with the Docker Environment. ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Chrome ### Operating System Windows 11

GiteaMirror closed this issue

2026-02-28 20:31:13 -06:00

GiteaMirror commented

2026-02-28 20:31:14 -06:00

@MatissJanis commented on GitHub (Jan 30, 2026):

Once a desktop app, mobile app, web app or any other version of actual uses the edge version - you cannot move back to the latest one (because that might mean loss of data).

This is not a bug.

Going forward I would recommend either using the latest version or edge. Never both.

@MatissJanis commented on GitHub (Jan 30, 2026): Once a desktop app, mobile app, web app or any other version of actual uses the edge version - you cannot move back to the latest one (because that might mean loss of data). This is not a bug. Going forward I would recommend either using the latest version or edge. Never both.

GiteaMirror commented

2026-02-28 20:31:14 -06:00

@MatissJanis commented on GitHub (Jan 30, 2026):

To explain more:

Your data is stored locally, on your device. That's the database.

With new features we sometimes run db migrations. To add tables, modify columns or do other things.

These migrations run on your local database as soon as you open the app.

If you open edge (and thus run the migrations).. and then move back to "latest" (which is an older version) - the local database becomes incompatible. It expects to see "edge", but is seeing "latest" and thus there is an error that you see.

@MatissJanis commented on GitHub (Jan 30, 2026): To explain more: Your data is stored locally, on your device. That's the database. With new features we sometimes run db migrations. To add tables, modify columns or do other things. These migrations run on your local database as soon as you open the app. If you open edge (and thus run the migrations).. and then move back to "latest" (which is an older version) - the local database becomes incompatible. It expects to see "edge", but is seeing "latest" and thus there is an error that you see.

GiteaMirror commented

2026-02-28 20:31:14 -06:00

@lavishtravel79 commented on GitHub (Jan 30, 2026):

To explain more:

Your data is stored locally, on your device. That's the database.

With new features we sometimes run db migrations. To add tables, modify columns or do other things.

These migrations run on your local database as soon as you open the app.

If you open edge (and thus run the migrations).. and then move back to "latest" (which is an older version) - the local database becomes incompatible. It expects to see "edge", but is seeing "latest" and thus there is an error that you see.

Why would it just start failing yesterday if I updated my Edge Container about 1 week ago? Even though I have two separate containers, each using a different database, it will still pose problems? How do you all test in a different environment then and still use stable at the same time? I may be misunderstanding something.

If my "local database" is called Test and is running at myserver:4006 (edge), that wouldn't be separate from my "local database" called Live Database that is running at myserver:5006 (Latest)?

Or is the "local database" something unique from my actual databases that I use in Actual? Still confused why it took several days for the issue to appear when I updated the Edge Container on January 25th, but was successfully running Bank Syncs the past 4 days in my Latest Container which is now failing.

@lavishtravel79 commented on GitHub (Jan 30, 2026): > To explain more: > > Your data is stored locally, on your device. That's the database. > > With new features we sometimes run db migrations. To add tables, modify columns or do other things. > > These migrations run on your local database as soon as you open the app. > > If you open edge (and thus run the migrations).. and then move back to "latest" (which is an older version) - the local database becomes incompatible. It expects to see "edge", but is seeing "latest" and thus there is an error that you see. Why would it just start failing yesterday if I updated my Edge Container about 1 week ago? Even though I have two separate containers, each using a different database, it will still pose problems? How do you all test in a different environment then and still use stable at the same time? I may be misunderstanding something. If my "local database" is called **Test** and is running at myserver:4006 (edge), that wouldn't be separate from my "local database" called **Live Database** that is running at myserver:5006 (Latest)? Or is the "local database" something unique from my actual databases that I use in Actual? Still confused why it took several days for the issue to appear when I updated the Edge Container on January 25th, but was successfully running Bank Syncs the past 4 days in my Latest Container which is now failing.

GiteaMirror commented

2026-02-28 20:31:15 -06:00

@MatissJanis commented on GitHub (Jan 30, 2026):

I'm not exactly sure how it happened for you, but somehow you loaded the edge build with both your budget files. And thus the migration was applied to the budget. And thus it can't safely go back.

Maybe you have some automation via the api? Those run the migrations too.

But yea.. it's only guesswork from me. The fact of the matter is that you're attempting to access a budget file that has been migrated to edge by using the "latest" version (ie an older version).

@MatissJanis commented on GitHub (Jan 30, 2026): I'm not exactly sure how it happened for you, but somehow you loaded the edge build with both your budget files. And thus the migration was applied to the budget. And thus it can't safely go back. Maybe you have some automation via the api? Those run the migrations too. But yea.. it's only guesswork from me. The fact of the matter is that you're attempting to access a budget file that has been migrated to edge by using the "latest" version (ie an older version).

GiteaMirror commented

2026-02-28 20:31:15 -06:00

@MatissJanis commented on GitHub (Jan 30, 2026):

Fyi: when I say "local database" - I mean exactly that. A database saved on your device, locally, in browser memory.

It is not stored in the docker env (altgough it does have a backup), it is not stored on a server or any other external source. Literally on your local machine.

This can be quite confusing to think about. It's not a classical setup where the DB is on the server (wherever that might be) and thus you can have multiple instances of the database. It is - instead - on your local device. As only a single database. Even if you host AB on 100 different servers - that's still only a single local database that all those servers share.

(I am paraphrasing and simplifying things.. but that's the jist of how local-first CRDTs work)

@MatissJanis commented on GitHub (Jan 30, 2026): Fyi: when I say "local database" - I mean exactly that. A database saved on your device, locally, in browser memory. It is not stored in the docker env (altgough it does have a backup), it is not stored on a server or any other external source. Literally on your local machine. This can be quite confusing to think about. It's not a classical setup where the DB is on the server (wherever that might be) and thus you can have multiple instances of the database. It is - instead - on your local device. As only a single database. Even if you host AB on 100 different servers - that's still only a single local database that all those servers share. (I am paraphrasing and simplifying things.. but that's the jist of how local-first CRDTs work)

GiteaMirror commented

2026-02-28 20:31:15 -06:00

@lavishtravel79 commented on GitHub (Jan 30, 2026):

Fyi: when I say "local database" - I mean exactly that. A database saved on your device, locally, in browser memory.

It is not stored in the docker env (altgough it does have a backup), it is not stored on a server or any other external source. Literally on your local machine.

This can be quite confusing to think about. It's not a classical setup where the DB is on the server (wherever that might be) and thus you can have multiple instances of the database. It is - instead - on your local device. As only a single database. Even if you host AB on 100 different servers - that's still only a single local database that all those servers share.

(I am paraphrasing and simplifying things.. but that's the jist of how local-first CRDTs work)

Appreciate the info. I guess the easiest solution is to wait for the upcoming release then, and when I pull the updated Latest Container it'll then be back on the same version as Edge was a few days ago and will fix itself.

I don't use the API, I simply use the Compose file I have that specifies Edge and the specific Port # to the Edge Container I have. I've never changed my compose file that specifies the Latest Build to its own specific Port #.

@lavishtravel79 commented on GitHub (Jan 30, 2026): > Fyi: when I say "local database" - I mean exactly that. A database saved on your device, locally, in browser memory. > > It is not stored in the docker env (altgough it does have a backup), it is not stored on a server or any other external source. Literally on your local machine. > > This can be quite confusing to think about. It's not a classical setup where the DB is on the server (wherever that might be) and thus you can have multiple instances of the database. It is - instead - on your local device. As only a single database. Even if you host AB on 100 different servers - that's still only a single local database that all those servers share. > > (I am paraphrasing and simplifying things.. but that's the jist of how local-first CRDTs work) Appreciate the info. I guess the easiest solution is to wait for the upcoming release then, and when I pull the updated Latest Container it'll then be back on the same version as Edge was a few days ago and will fix itself. I don't use the API, I simply use the Compose file I have that specifies Edge and the specific Port # to the Edge Container I have. I've never changed my compose file that specifies the Latest Build to its own specific Port #.

GiteaMirror commented

2026-02-28 20:31:15 -06:00

@MatissJanis commented on GitHub (Jan 30, 2026):

Either wait it out or you can also export the budget file on edge. And then import in the other version.

This might mean data loss though, so generally not recommended.

@MatissJanis commented on GitHub (Jan 30, 2026): Either wait it out or you can also export the budget file on edge. And then import in the other version. This might mean data loss though, so generally not recommended.