Open Bug 1781497 Opened 3 years ago Updated 6 days ago

Intermittent devtools/client/storage/test/browser_storage_indexeddb_navigation.js | single tracking bug

Categories

(DevTools :: Storage Inspector, defect, P3)

defect

Tracking

(Not tracked)

REOPENED

People

(Reporter: jmaher, Unassigned)

References

Details

(Keywords: intermittent-failure, intermittent-testcase)

No description provided.

Additional information about this bug failures and frequency patterns can be found by running: ./mach test-info failure-report --bug 1781497

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Status: REOPENED → RESOLVED
Closed: 2 years ago1 year ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Status: REOPENED → RESOLVED
Closed: 1 year ago11 months ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

Hi Marco,

When this test fails I see the following logs:

[task 2025-04-13T09:12:56.121Z] 09:12:56     INFO - Console message: [JavaScript Error: "Error: Error(s) encountered during statement execution: no such table: database" {file: "resource://gre/modules/Sqlite.sys.mjs" line: 1093}]
[task 2025-04-13T09:12:56.121Z] 09:12:56     INFO - Checking storage tree…
[task 2025-04-13T09:12:56.122Z] 09:12:56     INFO - Buffered messages logged at 09:08:58
[task 2025-04-13T09:12:56.122Z] 09:12:56     INFO - Console message: [JavaScript Error: "Warning: Sqlite connection '816800518dtbl-a.sqlite#0' was not properly closed. Auto-close triggered by garbage collection.
[task 2025-04-13T09:12:56.122Z] 09:12:56     INFO - " {file: "resource://gre/modules/Sqlite.sys.mjs" line: 95}]
[task 2025-04-13T09:12:56.122Z] 09:12:56     INFO - Console message: [JavaScript Error: "Error: Warning: Sqlite connection '816800518dtbl-a.sqlite#0' was not properly closed. Auto-close triggered by garbage collection.
[task 2025-04-13T09:12:56.122Z] 09:12:56     INFO - " {file: "resource://gre/modules/Sqlite.sys.mjs" line: 110}]

This happens right after we navigate to a new page and create new indexedDB database at
https://searchfox.org/mozilla-central/rev/08b2a1a770688df19a5a43fd89fb63b34bb2d6a6/devtools/client/storage/test/storage-indexeddb-simple-alt.html#16-27

async function setup() { // eslint-disable-line no-unused-vars
  await new Promise((resolve, reject) => {
    const request = indexedDB.open(DB_NAME, 1);
    request.onerror = () => reject(Error("Error opening DB"));
    request.onupgradeneeded = event => {
      const db = event.target.result;
      const store = db.createObjectStore("store", { keyPath: "key" });
      store.add({key: "foo", value: "bar"});
      store.transaction.oncomplete = () => resolve(db);
    }
  });
}

Called from the test at: https://searchfox.org/mozilla-central/rev/08b2a1a770688df19a5a43fd89fb63b34bb2d6a6/devtools/client/storage/test/browser_storage_indexeddb_navigation.js#34-39

await navigateTo(URL2);
info("Creating database in the second domain…");
await SpecialPowers.spawn(gBrowser.selectedBrowser, [], async function () {
  const win = content.wrappedJSObject;
  await win.setup();
});

Any idea what could cause such an error? It seems that the setup call never resolves or rejects so we timeout here.

Flags: needinfo?(mak)

indexedDB itself doesn't use Sqlite.sys.mjs, though devtools do that
Maybe the database file is there but the schema has not been created in it yet, or the schema change is still in the journal and this connection can't see it yet.

if that execute fails, then the next .close() call will also not be executed and I could see how Sqlite module would complain the connections have not been closed.

Flags: needinfo?(mak)

Thanks for the pointer! I actually was wrong in my first investigation. We seem to resolve the creation of the database in content, but we timeout waiting for the DevTools storage panel to update at https://searchfox.org/mozilla-central/rev/08b2a1a770688df19a5a43fd89fb63b34bb2d6a6/devtools/client/storage/test/browser_storage_indexeddb_navigation.js#41-42

info("Checking storage tree…");
await waitUntil(() => isInTree(doc, ["indexedDB", "https://example.net"]));

Let's see if I can retry the execute in the same way as we retry the the open in the area you linked to.

Let's see if I can retry the execute

That definitely helps, although I still have some failures with

Console message: [JavaScript Error: "NotFoundError: Could not stat `/tmp/tmp29htfv1y.mozrunner/storage/default/https+++example.net/idb/816800518dtbl-a.sqlite-journal' (NS_ERROR_FILE_NOT_FOUND)"]

Marco, is there a good way to know when it's safe to call execute ? I can keep the try / catch approach but that seems hacky.

Flags: needinfo?(mak)

(In reply to Julian Descottes [:jdescottes] from comment #40)

Marco, is there a good way to know when it's safe to call execute ? I can keep the try / catch approach but that seems hacky.

it should always be safe to call execute if the database open operation succeeded. Though, the result of executing the query depends on the underlying data, and there's no trivial way to tell in which state that data is when you query.

One thing I'd likely change here is passing readOnly: true option to openConnection, as I think you just want to read from the db, and not write to it, or even worse create a database at that path if it doesn't exist (openConnection would do that if the db file doesn't exist).
I'm not sure which code causes that stat error on the journal file, do you have a stack? though in read-only mode you shoudln't need a journal file.

Maybe indexeddb has its own methods to tell the state of a db, I'm not sure, Jan Varga may be a better person to ask about that.

Flags: needinfo?(mak)
You need to log in before you can comment on or make changes to this bug.