Graceful handing of corrupted cache index

[jgosmann]

Description:
Gracefully handles a corrupted cache index by clearing the cache an creating a new index.

Motivation and context:
In some instances the cache index can get corrupted (i.e. killing the process while the cache index is being written) and that would give an exception whenever one tries to use the cache. See #1097.

Interactions with other PRs:
Related to #1107 which makes it less likely to end up with a corrupted index.

How has this been tested?
Added a regression test, made sure it fails and fixed the problem which makes the test pass.

Where should a reviewer start?
Either the test or the fix depending on personal preference.

How long should this take to review?

• Quick (less than 40 lines changed or changes are straightforward)

Types of changes:

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• I have read the CONTRIBUTING.rst document.
• I have updated the documentation accordingly. (no changes necessary imo)
• I have included a changelog entry.
• I have added tests to cover my changes.
• All new and existing tests passed.

[mention-bot]

By analyzing the blame information on this pull request, we identified @tbekolay to be a potential reviewer

[tbekolay]

This looks good me, thanks for prepping this quickly! I added a commit to fix the flake8 error, and add some assert statements. The asserts aren't strictly necessary but feels like something should be asserted (I could be persuaded to leave them out).

This probably can use a changelog entry, which I could write in the merge. Can someone else look at this quickly, as it's the last thing for 2.1.1?

[hunse]

Yeah, LGTM.

[jgosmann]

additional commit LGTM, do you want to also include #1107 in 2.1.1?

[hunse]

I would not include #1107, since it still needs a bit more testing I think. Hopefully 2.2.0 will be out in a week or two, so it shouldn't be too long of a wait.

[jgosmann]

This probably can use a changelog entry, which I could write in the merge.

ok, leaving this to you. Didn't do it before because I first need the PR number and after I opened the PR I went for lunch before I was able to write the changelog.

[tbekolay]

Fair ;) Will do the merge now, then the release.

[tbekolay]

... after my lunch, that is.