Keep unrelated async work outside an IndexedDB save transaction

Choose a two-record save with no work left to invent

A fictional AI console wants to save two small browser-local metadata associations for an already reviewed artifact revision R-A: manifest reference M-A and provenance reference P-A. The useful result is the pair, not a green success notice for whichever operation happened first.

This proposed profile uses one trusted, already opened IndexedDB database, reviewed schema and two declared existing stores. It selects one short readwrite transaction T-A and two fixed ordinary requests. Both bounded operands, keys, associations and current rights must be ready before creation. The model chooses no store, command or transaction scope.

No database, records, transaction, requests or events were constructed for this article. All eight cards are PROPOSED_UNRUN. Actual browser support, adapter wiring, ownership, schema and current authorization remain unimplemented prerequisites; unknown evidence blocks the positive.

Treat activity as a finite scheduling opportunity

MDN’s IDBTransaction reference says a transaction starts when created. It is active in its creation task and in tasks for its requests’ success or error handlers, and inactive in other tasks. Placing requests while inactive fails. With no new requests placed while active and no outstanding requests, it automatically commits.

The selected plan therefore finishes unrelated preparation before T-A. It does not create T-A, wait for a model or network result, and assume a later callback can add P-A. That later unrelated task is not one of the documented active opportunities; the transaction may also have completed if the automatic conditions were met.

This is not a claim that every await has identical behavior. No microtask analysis, promise wrapper, transaction keepalive or explicit-commit technique is selected. A changed asynchronous adapter needs its own supported review rather than borrowing this worksheet’s outcome.

Know what each event actually establishes

The request success reference describes success of an individual IDBRequest. Its handler can access that request’s result and place more requests in the same transaction. It is not the whole application’s “saved” event.

The transaction complete reference instead describes successful transaction commit, including automatic completion after requests and result handling finish without new requests. Bind the observed event to the exact T-A and the intended request inventory.

For this profile, record whether both M-A and P-A requests were actually admitted, their dispositions, and T-A’s completion or failure. A completion event for a transaction containing only M-A cannot certify P-A. Conversely, both requests reporting success while transaction completion is unknown leaves the final save unresolved.

Use a ledger that can detect a missing second request

Keep the intended inventory separate from the submitted inventory. These are original review labels, not a database schema or implementation.

PROPOSED_UNRUN — selected local metadata save
Intent: R-A requires M-A and P-A, both prepared and admitted
Transaction: T-A | exact database/schema/stores | readwrite
Submitted requests: Q-M and Q-P, each bound to T-A
Request dispositions: recorded separately for Q-M and Q-P
Transaction disposition: complete / aborted / unresolved
Useful success: both intended requests accepted and successful,
                plus supported completion of that same T-A

The conditional positive queues the two prepared requests in supported active opportunities, with no unrelated asynchronous work between preparation and submission. After the full inventory and completion evidence match, the UI may describe only that local metadata pair as stored. No artifact bytes, model request or public release are part of the transaction.

Consider the rejected schedule: Q-M is queued, unrelated preparation is deferred, and no Q-P is submitted before T-A completes. A later failure to add Q-P does not establish rollback of M-A. The application failed to submit its intended group; database completion cannot manufacture the omitted request. Preserve that partial-plan outcome rather than silently opening another transaction and claiming one atomic save.

Walk eight inert scheduling and outcome cards

Keep failure handling and durability qualified

MDN’s failure discussion notes that a request error can lead to transaction abort, while preventing its default handling can change that outcome. This profile excludes error suppression. Inspect the actual terminal disposition rather than assuming every request error always settles the whole transaction the same way.

The same reference documents relaxed Firefox durability: complete can precede actual disk flushing. This worksheet therefore makes no universal crash-persistence claim and selects no experimental durability mode.

Unknown completion needs separately authorized reconciliation, not automatic replay or a new save that conceals uncertainty. Browser-local storage also does not establish allowed provider disclosure, current workspace rights, complete retained-copy deletion or an external file publication. Keep those decisions separate.

Limit the evidence to this proposed lifecycle

The three maintained MDN bodies were read on 30 October 2026, displaying modification dates 7 October 2026, 2 May 2025 and 26 October 2026. They identify no tested browser build, actual database or installed wrapper. No candidate IndexedDB, browser, request, event, transaction, model/network wait or runtime fixture was exercised.

Boundary is prelaunch and does not ship this browser-storage coordinator. Its existing synthetic action evidence covers different behavior. The file publication guide addresses a later, different boundary; neither it nor this worksheet promises atomicity with external files, safe arbitrary data or exactly-once effects.