...
Because you can run the Risky Code Changes slice over extended periods of time, the slice includes a caching mechanism to speed up multiple requests for the same data. When data is requested for a filter, the slice first determines if the data is already computed and cached. If the cache exists, the data is returned directly and the lengthy computation is skipped. The cache is cleared and recomputed on the fly, however, if the data is not cached, if the cached data is for a different build combination, or if more analysis data has been reported to the build combination, then the cache is cleared and recomputed on the fly. There is a maximum of one cache per filter and combination of baseline and target build.
| Anchor | ||||
|---|---|---|---|---|
|
Because the slice does not automatically remove cached data, the cache can grow as more filters are introduced. To help you clear out old cache data, the slice provides a way to delete all cached calculations from the PIE database. This flow cleans all cached calculations. The cache also clears at 00:00 every day. You can configure the auto cache clearing setting by editing the Clean Cache inject node.
...
Verify that the filter has a coverage image associated with it (see Associating Coverage Images with Filters) and that the correct coverage image was selected when you added the widget (see Widget Configuration).
If an error persists after you have addressed the root cause, you may need to clear the cache.