Possible benefit to using synchronous-promise

[retorquere]

Given the description here, firebase uses a specialized pseudo-Promise to guard against early commit on indexedDB transactions. synchronous-promise could maybe provide the same?

[MockingMagician]

Nice, I read all the papers and they was very instructive, thanks. I think, the important part of the idea used in firebase is in this file:

https://github.com/firebase/firebase-js-sdk/blob/2561b6306aa4a8f6fc6b75fe0a6d4bfeeef61d2a/packages/firestore/src/local/persistence_promise.ts#L29-L42

I'm going to keep all this in a corner of my mind

[retorquere]

Yeah that's the part, but I think the synchronous promise implements the same concept.

[MockingMagician]

synchronous-promise seems to have the advantage of being a little more compatible with the promises in terms of its API, since you can chain block then/catch operations, which firebase's API doesn't seem to offer, but which seems to have been designed only to handle the particular case of indexedDB.

My gosh, the original indexedDB implementation is so weird.

Anyway, I'd start with a test that fails when executing transactions within the promise framework. And then I'd see which one inspires me the most and offers the most comfort for the user.

[MockingMagician]

By the way @retorquere if you've ever encountered this problem of failed transactions in this context, I'd appreciate it if you could provide some examples.

[retorquere]

I am having problems which I thought were related to this, but it has turned out to be something different. Still, SyncPromise seems like a prudent approach given the weirdness of the indexedDB API, and clearly Firebase has experienced this problem.

[MockingMagician]

Hi @retorquere

I was able to reproduce the behavior of a self-committing transaction in the context of a block then that would perform an action that took too long. If you want to take a look:

https://github.com/MockingMagician/promised-db/blob/5c9e1b2582141ee2c858757225765d50cdd01312/test/component/test.transaction.real-env.test.ts

[retorquere]

I'm not sure synchronous promises would help there - setTimeout itself would yield to the event loop. I think what firebase was protecting against was the issue that promises themselves would yield to the loop, effectively a setImmediate to call the then handler, which would yield and therefore commit, regardless of whether you do async work in the handlers.

[MockingMagician]

I just wanted to try and reproduce the behavior of an eventLoop call. I tried with different promise consumers (even a few thousand) but without success. The only way I actually found to reproduce this behavior was to call setTimeout or fetch, whose then resolution makes a call to eventLooop.

I think the only real thing to respect and remember is not to do anything other than write your data during a transaction, otherwise disaster strikes lol

As I'm writing, I'm thinking of a case where it seems to have already happened to me, when I went to read data from two different entry points. I'll have to try and reproduce it.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.