fix(gatsby): purge jobsV2 results when cache is corrupt

[vladar]

Description

We consider Gatsby cache to be corrupt when a user deletes the public folder but not the .cache folder. In this case we purge the cache for him (via #27549) and also call DELETE_CACHE to purge the redux state that is already in memory by this point.

But jobsV2 reducer doesn't clear job cache on DELETE_CACHE action. This makes sense because sharp jobs can survive .cache folder removal. But they can't survive the public folder removal (as that's where job results are physically stored).

This PR changes the behvaior of jobsV2 reducer and makes it purge the job cache when the cache is corrupt (so only when the public folder is deleted).

Related Issues

Fixes #27699

[wardpeet]

Well, in the long run this isn't the right fix. We should be able to check if the output file still exists. If it does then we can keep it. If not we mark it as stale. Currently, we're not saving the files inside the cache so it would be more work than this PR.

Why is this relevant? Jobs API shouldn't just be used for files but can also be used for data like markdown transformations which never get stale as the contentDigest takes care of it.

[vladar]

Agreed, we need a better fix for this. But we don't know output artifacts of jobs to check if they exist. So that's just a workaround.

Also, it's a very edge case - when people delete their public folder but not .cache (see details in the linked issue).

In the past this would just throw a bunch of errors and wouldn't work at all. But now that we delete the .cache folder when public is not there - the build actually succeeds but transformed images are not there.

It happens because we load redux state from cache before we actually delete the .cache folder and so we emit this DELETE_CACHE action to make sure in-memory redux state is also purged:

gatsby/packages/gatsby/src/services/initialize.ts

Lines 277 to 281 in 878a8ab

	// Tell reducers to delete their data (the store will already have
	// been loaded from the file system cache).
	store.dispatch({
	type: `DELETE_CACHE`,
	})

Far from pretty 😕