IndexedDB versionchange transaction rollback consistency across browsers

The HTML5 IndexedDB specification defines the versionchange transaction as an atomic operation. When an error occurs during a schema update, the transaction should abort, leaving the database at its previous version and reverting any structural changes made during that session.

In complex migrations involving the creation or deletion of multiple object stores, there is uncertainty regarding the guarantee of a full rollback across different browser engines. While the specification mandates atomicity, implementation variances may lead to partial commits if an error is triggered after some stores have already been modified but before the transaction completes.

This creates a risk where the database version remains unchanged, but the internal schema state is inconsistent.

• Does the versionchange transaction guarantee a complete rollback of all structural changes across all major browser engines when an abort is triggered?
• How should developers verify that no partial schema updates persisted after a failed version migration?