Re: [w3c/IndexedDB] treat writes to the DB that have no success handler as having called commit (Issue #482)

asutherland left a comment (w3c/IndexedDB#482)

I agree that this would both be:
- A great potential optimization if we could have a concept of unobserved requests that we don't need to send any IPC back for many requests.
- A great Developer eXperience (DX) improvement since the intent in the situations you cite where they global may be going away/into bfcache is usually quite clear.

That said, this would also be a massive change in semantics, although we definitely have precedent with ServiceWorker's special semantics around [FetchEvent and the respondWithEntered flag](https://w3c.github.io/ServiceWorker/#ref-for-fetchevent%E2%91%A3) where it is necessary to call respondWith within the task.

Is this something you could gather metrics on in the wild about success and error handlers added after the dispatch completes (which also should have drained the microtask queue)?  It would be a weird idiom, but one could imagine a middleware-ish layer that operates like the following, possibly to support open-ended commit lifetime extension due to a lack of a waitUntil() mechanism or due to concerns about the amount of time/latency required to create new transactions/etc.:
- When issuing a new request, check if we know we have an outstanding "success" handler `saveReq`.  If we do, save off the current request as `lastReq` but do not add a success handler, otherwise add a "success" handler and mark that as `saveReq`.
- When we receive a "success" event, if `lastReq` is not `saveReq` and we're `saveReq`, add a new success handler to `lastReq`.

I don't think the above is particularly a good or reasonable idiom, but this breaking change would partly be in service of code that doesn't keep up with changes to the IndexedDB API (since `commit` is available), and wacky code like the above would also fall into that, so it would be great to have telemetry data confirming it's not something we need to worry about breaking or that it's very rare.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/482#issuecomment-3468090677
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/482/3468090677@github.com>