Clean up of expired interest groups

[iamnewton]

When do we clean up the expired groups? After the auction? Upon updating/adding to a new interest group?

Depending on when we clean up, there could be a race condition (may not be that big a deal) whereby you’re deleting an interest group from an expired session right before an auction.

[brodrigu]

My suggestion:

Clean up interest groups after each joinAdInterestGroup() call. We already need to do a read and write and we can take more time here to do the cleanup. We may be able to use one or more mutex to prevent race conditions on a given page load (and possibly reduce them across page loads).

Maybe we implement naively without a mutex and create an issue to add this protection later.

[iamnewton]

How far do we go to clean up? The current specification has us storing things by a top-level owner key.

That means when we're deleting interest groups, we'd be deleting the nested Object with the name key and so we'd have to look up if there are any hanging/empty owner objects. Do we want to do that?

[brodrigu]

I would say yes, if we know we are deleting the last interest group for an owner, delete the owner key as well.

[iamnewton]

Thinking out loud, but that would mean, as we loop through to remove a group, we'd have to look at the parent owner and if there is only 1 key that we're removing, then we remove the group. Are we concerned with a possible race condition of removing the owner, and someone being added to that group by accident, such as maybe hitting the refresh button right as we're cleaning up in another session?

[brodrigu]

Yeah, I think we are on the same page as to how this would be implemented.

We should try to store data in a way that limits possible race conditions, and to document cases were we think they could exist. However, I believe the IndexedDB API has transactional support which would make the update an atomic operation and hopefully prevent any race conditions.

[iamnewton]

Sounds good. Seems like we're agreed, depending on support and implementation details following #7

[iamnewton]

What if we clean up only when the storage limits get close:

if (navigator.storage && navigator.storage.estimate) {
  const quota = await navigator.storage.estimate();
  // quota.usage -> Number of bytes used.
  // quota.quota -> Maximum number of bytes available.
  const percentageUsed = (quota.usage / quota.quota) * 100;
  console.log(`You've used ${percentageUsed}% of the available storage.`);
  const remaining = quota.quota - quota.usage;
  console.log(`You can write up to ${remaining} more bytes.`);
}

And maybe we start the clean-up process only if the quota is close to 80%? Thoughts?

Support: https://caniuse.com/mdn-api_storagemanager