Problem with migration during app downgrade

[Elendiar]

Problematic behavior detected when downgrading a program. High cpu load and memory leak after while without any console.log message.

Dexie function calls

I noticed that rx-migration-state-meta is constantly being recreated on deletion and updated. And there is definitely some problem in this.
All workplaces migration was just 1: (oldData) => oldData

Timestamps are constantly updated.

When deleting the IndexedDb the problem is solved.
But the problem is that such behavior is hidden and it may not be noticed right away, which will lead to a problems in case of mass program downgrade.

[pubkey]

Hi, can you create a test case to reproduce this behavior?

[Elendiar]

@pubkey Hello reproduce this in https://github.com/Elendiar/rxdb-issue-test-case

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon. Please update it or it may be closed to keep our repository organized. The best way is to add some more information or make a pull request with a test case. Also you might get help in fixing it at the RxDB Community Chat If you know you will continue working on this, just write any message to the issue (like "ping") to remove the stale tag.

[pubkey]

@Elendiar are you increasing the schema version and then redeploy it with a downgraded version number? Because this is not supported, the migration only works in one direction.

[Elendiar]

@pubkey Yes, but is it possible to handle this somehow to avoid implicit use of resources?

[pubkey]

Not sure, I do not see any reason for downgrading a schema version at any point.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon. Please update it or it may be closed to keep our repository organized. The best way is to add some more information or make a pull request with a test case. Also you might get help in fixing it at the RxDB Community Chat If you know you will continue working on this, just write any message to the issue (like "ping") to remove the stale tag.

[stale]

Issues are autoclosed after some time. If you still have a problem, make a PR with a test case or to prove that you have tried to fix the problem.

[Elendiar]

By the way, the problem still exists. If anyone needs a guaranteed reliable launch of the application, they can use something like this after call addCollections

private async handleMigrations(collections: Record<string, RxCollection>) {
		for (const collection of Object.values(collections)) {
			if (!(await collection.migrationNeeded())) continue;

			const migrationsState = collection.getMigrationState();
			const subscription = migrationsState.$.subscribe({
				error: (error) => {
					this.log.error(
						`Error during migration ${collection.name}: ${JSON.stringify(error).slice(0, 100)}. Delete database and reload application.`,
					);
					this.deleteDatabaseAndReload();
				},
			});

			const timeout = setTimeout(() => {
				this.log.error(
					`Database collection [${collection.name}] takes too long to migrate. Delete database and reload application.`,
				);
				this.deleteDatabaseAndReload();
			}, 6000);

			await collection.startMigration(1);
			clearTimeout(timeout);
			subscription.unsubscribe();
		}
	}

set collection automigrate: false, than handle migration manually.
But before startMigration set timeout, becase when this issue happens (with high cpu load and memory leak), migration doesn't finished (only next emitted once with done state, no any errors emitted).
If migration takes too long, just reload app with fresh database. Yeah, you lost data, but in my case it's ok, unlike the load on the processor and a crash in the future due to a memory leak.