Schema migration hangs forever instead of rejecting when the migration replication errors

[danh65]

In migrateStorage (src/plugins/migration-schema/rx-migration-state.ts) the replication's errors are recorded but never acted on:

let hasError: RxError | RxTypeError | false = false;
replicationState.events.error.subscribe(err => hasError = err);

await awaitRxStorageReplicationFirstInSync(replicationState);
await awaitRxStorageReplicationInSync(replicationState);
await this.updateStatusQueue;
if (hasError) { /* ... */ throw hasError; }

If the replication errors before reaching first-in-sync, the first await never settles, so the if (hasError) below it is unreachable. migratePromise() never settles, addCollections() never resolves, and an app that awaits it before mounting shows a blank page with a completely clean console — there is no error to find, because nothing rejected.

Observed on 16.18.0 with the Dexie storage. The migration status doc sits at status: 'RUNNING', count.handled: 0, with count.total correctly populated (counting happens before the replication starts, so the totals look healthy while nothing is progressing).

Driving the same migration directly via getMigrationState().migratePromise() surfaced it properly as DM4 with DatabaseClosedError: Database has been closed — confirming an error was raised and then swallowed by the unreachable check.

Suggested fix: settle on the first error rather than after sync, e.g. race the awaits against a promise that rejects when events.error emits.

This is distinct from #8871, which removes one cause of an interrupted migration. This report is about any storage error during a migration being unobservable to the caller: the failure mode is a hang rather than a rejection, which makes it very hard to diagnose from the application side.

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