Improve example usage for strict durability

[evanstade]

Currently, the example for strict durability buckets is an offline drafts folder for an email client, but this is not a great usage for strict durability. Using strict durability reduces the likelihood of data loss by a very small margin and the most important effect is that it will confirm that the data has been written. Yes, the data may be saved slightly faster with strict durability, but more importantly, the transaction won't be confirmed until after the disk is modified.

The large majority of applications should never need strict durability, which is why buckets default to relaxed. MDN docs say this: "there exists a small chance that the entire transaction will be lost if the OS crashes or there is a loss of system power before the data is flushed to disk. Since such catastrophic events are rare most consumers should not need to concern themselves further." which I believe is more appropriate because it doesn't encourage the usage.

I am currently struggling to think of a compelling, concrete use case for strict durability that can be used as an example. It doesn't guarantee atomicity in the bucket because storage APIs still don't synchronize. Durability could be used to move data from one store to another, for example if migrating from bucket A to bucket B, the deletion from A should not occur unless B has confirmed writing. However this isn't really a case where the bucket should default to strict; only an individual transaction or set of transactions should do so.

[evanstade]

@asutherland @ayuishii thoughts?

[ayuishii]

Thanks for explaining. I think I agree that durability makes more sense per-transaction level. Especially understanding the performance impact of this more, it sounds like it should be used in a more intentional way per transaction, than a blanket setting on a bucket level. Also to prevent those from setting "strict" for everything, because it seems safer.

[asutherland]

I see a new commit just landed around durability while I was looking into this issue that I won' t be able to process in full today, but I will say that prior to that landing I don't know that this bit of text about "relaxed" would apply to what Gecko would implement or I think would be reasonable to impose on implementations:

Also, power failures will not lead to data corruption at a higher rate than for "strict" buckets.

My mental model of "relaxed" was roughly "go-fast"/"yolo" where it's fine to lose the data occasionally in the service of speed.

[evanstade]

Thanks for taking a look!

I see a new commit just landed around durability while I was looking into this issue that I won' t be able to process in full today, but I will say that prior to that landing I don't know that this bit of text about "relaxed" would apply to what Gecko would implement or I think would be reasonable to impose on implementations:

Also, power failures will not lead to data corruption at a higher rate than for "strict" buckets.

My mental model of "relaxed" was roughly "go-fast"/"yolo" where it's fine to lose the data occasionally in the service of speed.

I think the key distinction is corruption vs loss.

We are not closed to the idea of reintroducing durability, but we would want to know that it's useful and ideally it would apply elsewhere besides just IDB (such as in the Bucket File System). It's no longer a part of our planned MVP for Chromium. I removed it from the explainer to avoid confusion while it is being determined whether to keep it.