.remove method seems to leave stale data behind?

[Schwartz10]

I'm not sure if this is something I'm doing wrong, or if there's a bug somewhere...

Basically I have a test suite that cleans up after itself.

At the beginning of the tests, we do something that looks like this:

    await idx.set("permissions", { 
      permissions: {}
    });

At the end of the tests I do something like this:

await this._idx.remove("permissions");
const resetPerms = await this._idx.get('permissions')
// returns null as expected

No errors get thrown.

Yet after setting anything on permissions alias, the old state returns:

await idx.set("permissions", { 
   permissions: {}
});

const perms = await idx.get('permissions')
/*
returns old state from last round of tests:
permissions: {
   qmz123: ['*'],
   qmz456: ['READ', 'WRITE']
}
*/

Even manually idx.set('permissions', null) won't do the trick for me either - seems to just not do anything.

PS:

I know it's a bit weird that I have a permissions object as a nested layer inside the permissions collection in the IDX root - the idea here is that (eventually) I'll replace permissions with some DocID, so that if I want to add/remove permissions from this list, I can just update that associated doc without touching the IDX root. I think this will just make the migration a bit smoother and help avoid breaking changes.

[PaulLeCam]

Hey, thanks for reporting this!

Basically what remove() does is remove the definition key from the index, it doesn't affect the referenced contents at all, but I get how that can be misleading, maybe we could add an option to this method to also delete contents?
I think that can be misleading though is that even if it deletes the referenced document, this document itself may reference other documents so this wouldn't be a "deep" removal of all the documents.

Regarding the old contents being returned after new contents are set, that's unexpected indeed! I'll need to dig into this to reproduce the issue.