Bug Description

When utilizing the website search functionality, it caches indexable pages and their respective content. Additionally, it saves the FlexSearch index within a unique IndexedDB table. This table's uniqueness is defined by a random UUID, generated for every build. Generally, this doesn’t pose a problem since the IndexedDB usually undergoes clearing at a regular interval.

However, complications arise when the ATT&CK website undergoes frequent automatic redeployments through CI/CD, such as every 30 minutes. Under these conditions, it's plausible for the IndexedDB to accumulate duplicate table instances, each differentiated by a unique UUID.

We've received reports indicating that the IndexedDB's storage usage reached up to 1.2 GB. This not only poses storage issues but also triggers a warning pop-up notification for Safari users.

Possible Solutions

1. Introduce a "garbage collector" within the search bundle to eradicate older IndexedDB tables.
2. Refine the workflow determining the initiation of a new IndexedDB table. Instead of relying on the build-specific UUID, consider the specific version of the ATT&CK website and STIX content.
3. Avoid altering the UUID with every build. Propose establishing a global constant, committed to version control, which only changes upon updates to the ATT&CK website version or STIX content. This can also be managed using a static map.