Closed Bug 1598555 Opened 3 years ago Closed 1 year ago

QM: Move ambiguous storage initialization failures under a new key

Categories

(Core :: Storage: Quota Manager, task, P3)

task

Tracking

()

RESOLVED INVALID

People

(Reporter: janv, Assigned: tt)

References

(Blocks 1 open bug)

Details

Attachments

(1 obsolete file)

For example IDB_GetDBFilenames is now reported as an external error:
https://searchfox.org/mozilla-central/rev/581466eef9269afb03d8a0dba2f50215f3a9026c/dom/indexedDB/ActorsParent.cpp#16240

However, GetDatabaseFilenames can fail due to an internal or external error.
We should either try to be more precise in cases like this or use a new key for this: "ambiguous".

Tom, you can take this one if you want.

Sure.

For this case, one thing I notice is that, unknown files inside the idb directory would cause this error.

Also, even after we fix that, we probably want to collect more precise data (e.g. which function returns error inside the GetDatabaseFilenames) rather than only tracking the returning error for GetDatabaseFilenames.

(I assume this bug blocks bug 1594080 since that bug is going to ignoring this error for initialization).

Assignee: nobody → ttung
Blocks: 1594080
Status: NEW → ASSIGNED

Yeah, but this bug is more about auditing all errors and moving ambiguous ones under the new key.

So for the old telemetry (QM_INIT_TELEMETRY_ERROR):

  • Continue traverse directories even an error is found on Nightly.
  • Report for each attempt
  • Not precise enough
  • Nightly only

For the new telemetry, we want:

  • Continue traverse directories even an error is found on all channels, but only for the first run.
  • Report for the first attempt
  • Add new key "ambiguous"
  • All channels

Jan, does that sound good to you? Or, we should probably focus on adding new key "ambiguous" only in this bug.

Flags: needinfo?(jvarga)

Yes, we will have to do something with the old telemetry before renewing it, but this bug is just about improving the classification of errors.
Currently there are only two keys, internal and external. However, there are situations where we don't know if it was an internal or external error.
For example, when GetDatabaseFilenames fails, we report it as an external error (IDB_GetDBFilenames), but inside the method there are places where it can fail due to internal or external error.
As a first step, I want to move these cases under a new key "ambiguous".

Flags: needinfo?(jvarga)
Blocks: 1600352

Unassign me since I will be on vacation for several weeks. People in the worker-and-storage team are welcome to take it.

Assignee: ttung → nobody
Status: ASSIGNED → NEW
Assignee: nobody → ttung
Status: NEW → ASSIGNED

I will re-visit this if the failure rates of initialization functions won't be lower after fixing existing suspicious issues which causing initialization failures (bug 1594075, 1536796).

Depends on: 1594075, 1536796

I guess I shouldn't add the dependencies. I am working on Bug 1594075, and bug 1536796 and plan to visit on this after that. They do not directly block this bug.

No longer depends on: 1536796, 1594075
Priority: P2 → P3
Attachment #9112290 - Attachment is obsolete: true

We have QM_TRY stuff to collect data and the old telemetry probe has been removed

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.