Open Bug 1705304 Opened 3 years ago Updated 7 months ago

[QM_TRY] Add propagation path for FATAL errors

Categories

(Core :: Storage: Quota Manager, enhancement)

enhancement

Tracking

()

People

(Reporter: jstutte, Unassigned)

References

(Blocks 25 open bugs)

Details

The monitoring of failures confirms, that there are some error conditions we cannot meaningful recover from and should inform the user about.

As a first step towards this direction, we want to introduce a FATAL failure level, that should let fall through the associated error along the propagation path up to our highest level of abstraction without further mitigation attempts.

To motivate this better, we will also collect here error conditions encountered so far that most probably need this.

Clients Sessions Hits Anchor Stack
3 5 5 dom/quota/ActorsParent.cpp:GetBinaryInputStream dom/quota/ActorsParent.cpp#2582:WIN32(0x570) <- dom/quota/ActorsParent.cpp#4555:WIN32(0x570) <- dom/quota/ActorsParent.cpp#4628:WIN32(0x570)
See Also: → 1702421
See Also: → 1702422
Clients Sessions Hits Anchor Stack
1 1 1 QuotaCommon.h#1379:NS_ERROR_FILE_FS_CORRUPTED <- ...
See Also: → 1702595
See Also: → 1703269
Clients Sessions Hits Anchor Stack
30 85 287 dom/quota/QuotaCommon.h:CollectEachFile QuotaCommon.h#1177:WIN32(0x570)

Now mapped to NS_ERROR_FILE_FS_CORRUPTED.

See Also: → 1703270
Clients Sessions Hits Anchor Stack
1 1 1 dom/quota/ActorsParent.cpp:QuotaManager::CopyLocalStorageArchiveFromWebAppsStore dom/quota/ActorsParent.cpp#5556:NS_ERROR_FILE_NO_DEVICE_SPACE <- dom/quota/ActorsParent.cpp#5844:NS_ERROR_FILE_NO_DEVICE_SPACE <- dom/quota/ActorsParent.cpp#5848:NS_ERROR_FILE_NO_DEVICE_SPACE
See Also: → 1704440
See Also: → 1704433
See Also: → 1706006
Blocks: 1704444
Blocks: 1706006

We should consider all NS_ERROR_FILE_FS_CORRUPTED instances, as those in D113518.

See Also: → 1690326
Blocks: 1703269
See Also: 1703269
Blocks: 1708130
Blocks: 1709059
Blocks: 1704442
Blocks: 1704434
Blocks: 1703801
See Also: 1703801
Blocks: 1704440
See Also: 1704440
Blocks: 1703271
See Also: 1703271

One thing that would be great to have here is a list of impacted public web platform APIs and then for each of those APIs detail:

  1. What the respective specification says a fatal I/O error should mean for this API. (If it doesn't say anything, let's file an issue to discuss with others and link that instead.)
  2. What our implementation will do. (It might take a while for the specification to be updated and it seems useful to capture what we do in the interim or in case we decide not to prioritize aligment.)

(One example that came up (unsure if theoretical) is that the window.indexedDB getter might have to handle a fatal I/O error in a special way whereby it still returns an object, but operations on that object end up failing. As the getter itself ought not to throw per the specification and always return the same object, but if an implementation lazily creates that object it might erroneously decide to surface a fatal I/O error during creation.)

Depends on: 1711691
Blocks: 1705013
Blocks: 1702422
Depends on: 1711693
Blocks: 1711693
No longer depends on: 1711693
Blocks: 1704438
Blocks: 1746432
Blocks: 1708127
Blocks: 1702598
See Also: 1704438, 1702422, 1706006
Blocks: 1780048
Blocks: 1720087
Blocks: 1704439
Blocks: 1703266
Blocks: 1803617
Blocks: 1704433
Blocks: 1815289
Blocks: 1714971
Blocks: 1855352
You need to log in before you can comment on or make changes to this bug.