Write an IndexedDB add function with transaction error handling

What's really being asked

The interviewer wants to see if you know that IndexedDB has two distinct failure surfaces: the individual request and the transaction that encloses it. Many developers treat IndexedDB like a simple promise-based API and forget that transactions can abort for reasons unrelated to a single request, such as quota exceeded errors, schema violations, or explicit abort calls. This question separates candidates who have read the MDN docs from those who have actually shipped code against the API.

The full answer

First, open a readwrite transaction on the database and retrieve the object store by name. Second, call add with the payload and optional key, which returns an IDBRequest. Third, attach onsuccess and onerror to that request so you can react to per-record outcomes like constraint errors. Fourth, and most critically, attach onabort and onerror to the transaction itself because a request can succeed while the transaction later aborts. Fifth, mention that add throws a DOMException immediately if the key already exists, unlike put which would overwrite. Sixth, wrap the logic in a function that accepts the database, store name, and value, returning control to the caller via callbacks or a promise that listens to both request and transaction events.

The mistakes people make

A frequent red flag is only wiring onsuccess and onerror on the request and ignoring the transaction entirely. Another is assuming that a successful request guarantees committed data; in IndexedDB, the commit happens at the transaction boundary, not the request boundary. Some candidates also confuse add with put and do not mention that add is strict about duplicate keys. Writing async await code that looks synchronous but omits error handlers is another sign of shallow experience. Finally, forgetting to open the transaction in readwrite mode and leaving it in the default readonly mode will cause the add operation to fail silently or throw immediately.

What usually comes next

The interviewer might ask how you would promisify this safely, how to handle version upgrades with onupgradeneeded, or what happens when the same database is opened in another tab. They may also ask about indexing strategies, pagination with cursors, or how to implement bulk inserts without blocking the main thread. Be ready to discuss error recovery patterns, such as retrying with put after an add constraint error, or using explicit transaction abort for rollback semantics.

A concrete example

Imagine a notes app saving a new note object with an auto-incrementing key. You open the database, start a readwrite transaction on the notes store, and call store.add with an object like title Meeting and body Q3 planning. The request onsuccess fires with the generated key, but if the user is over storage quota, the transaction onabort fires afterward and the data is not persisted. A robust implementation catches both, surfacing a saved locally toast for request success but rolling back the UI if the transaction aborts.