The IndexedDB Model

## The rule IndexedDB transactions are short and self-closing. You do not begin and end them; you create one with `db.transaction(storeNames, mode)` and the browser decides when it is over. A transaction has a state — **active** or **inactive** — and requests may only be issued while it is active. A transaction is active in exactly two situations: during the turn in which it was created, and inside the `success` or `error` handler of one of its own requests. It becomes inactive as soon as control returns to the event loop, and once inactive with no outstanding requests, the browser **commits** it. Any request issued against an inactive transaction throws `TransactionInactiveError` synchronously. ```js const tx = db.transaction('orders', 'readwrite'); const store = tx.objectStore('orders'); store.put(a); // fine — same turn store.put(b); // fine — still the same turn tx.oncomplete = () => console.log('committed'); ``` That design is deliberate. Because a transaction cannot be held open across arbitrary waits, one tab cannot lock a store while it waits on a slow server, and the database cannot be wedged by a page that forgot to close something. ## Why the fetch kills it ```js const tx = db.transaction('orders', 'readwrite'); const store = tx.objectStore('orders'); store.put(local); // committed const res = await fetch('/api/order'); // control returns to the event loop store.put(await res.json()); // TransactionInactiveError ``` A network response cannot arrive in the turn that started the request. Control necessarily goes back to the event loop, the transaction has nothing pending, and it commits. The later `put` is a call against a finished transaction. The crucial detail for a production answer: **the first write is not rolled back**. A commit is a commit. You have not lost the transaction's work, you have narrowed the transaction to less than you intended, and the atomicity you thought you had is gone. A partially applied migration or a queue entry written without its companion record is the real-world damage. ## Why promise wrappers still work Libraries that wrap IndexedDB in promises appear to defy this, and do not. Their promises settle within the same turn's microtask checkpoint, so the next request is still issued while the transaction is active. Anything that needs a *fresh task* — a network response, a timer, a message from a worker, an image decode — is on the other side of the line and will always find the transaction closed. The distinction to state in an interview is not "await is bad" but "await something that cannot settle this turn is bad". ## How to restructure Order the work so IndexedDB is a tight block: ```js const payload = await fetch('/api/order').then((r) => r.json()); const tx = db.transaction(['orders', 'outbox'], 'readwrite'); tx.objectStore('orders').put(payload); tx.objectStore('outbox').delete(payload.id); await new Promise((resolve, reject) => { tx.oncomplete = resolve; tx.onerror = () => reject(tx.error); tx.onabort = () => reject(tx.error); }); ``` Three points fall out of that shape. Every store you will touch must be named when the transaction is created — reaching for a store outside the transaction's scope raises `NotFoundError`, and scope cannot be widened later. Completion is observed on the *transaction*, via `complete`/`error`/`abort`, not on the last request; a request succeeding does not mean the data is durable. And `tx.abort()` is the explicit escape hatch that rolls back everything the transaction did, which is how you turn a failed validation into a clean no-op. ## Modes, scope, and concurrency `readonly` is the default-safe mode and multiple readonly transactions over the same store run concurrently. `readwrite` transactions whose scopes overlap are serialised, and — importantly — they run **in the order they were created**, not the order their first request is issued. Creating a readwrite transaction over a hot store and then leaving it idle blocks later writers behind it. Asking for `readwrite` when you only read is a real, if small, throughput cost. Browsers also expose an explicit `transaction.commit()` to end a transaction as soon as you know you are done rather than waiting for the auto-commit check, which shaves latency on chatty write batches. It does not change any of the rules above. ## What people get wrong Assuming the failed write means nothing was written; blaming `await` in general instead of naming which awaits cross a task boundary; calling `store.get` on a store that was never in the transaction's scope; and treating a request's `success` event as proof of durability when only the transaction's `complete` event says so.