Invalid coverage caches: fail or recreate?

[dievsky]

java.lang.IllegalStateException: Cache file [cache].npz doesn't contain chr6_ssto_hap7/+.
It's likely that chrom.sizes file used for its creation differs from the one being used to read it now.
If problem persists, delete the cache file [cache].npz and Span will recreate it with correct settings.

[dievsky]

Though on further thought, there's not much we can do about it. It's too dangerous to just ignore the missing data. The one thing that we could do is to force Span to recreate the cache if it's invalid, instead of informing the user that they should do it.

[olegs]

Luckily JBR is compatible!

[dievsky]

Mostly because JBR doesn't use the coverage cache files. :))

[dievsky]

So, to reiterate, the question is: should Span just delete and create coverage caches if invalid, or continue to fail with an exception, like now?

Pros:

• more seamless behaviour after coverage cache format change;
• less user actions required.

Cons:

• in a case of some unexpected bug Span can get stuck in recreating the cache on each launch;
• some valid caches could be deleted by mistake.

It should be noted that cache creation normally takes only about a few minutes. Anyway, there's no need to change this in the upcoming release. This can wait until a later time.

[olegs]

I think that failure is better option here, given the user instructions how to overcome this. Deleting something by mistake is worse than making user to remove caches manually.

[dievsky]

If you say so. (Deleting a cache is not such a big deal, though.) Since instructions are already being provided, I'm closing this as won't-fix.