Try to automatically rebuild meta index on index format error

[ewillink]

eclipse.buildId=4.27.0.I20230302-0300 java.version=17.0.6 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_GB Command-line arguments: -os win32 -ws win32 -arch x86_64 -clean -data E:\Development\Chital\Workspace

I have been observing frequent malfunction of searches and import quickfixes and finally noticed that at the root of this problem is the 'loss' of a plugin as consequence of the error entry below. (The lost plugin is ignored from all search results.)

java.io.IOException: Wrong format at org.eclipse.jdt.internal.core.index.DiskIndex.initialize(DiskIndex.java:410) at org.eclipse.jdt.internal.core.index.Index.(Index.java:120) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.loadMetaIndexIfNeeded(IndexManager.java:1657) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.findMatchingIndexNames(IndexManager.java:1568) at org.eclipse.jdt.internal.core.search.IndexSelector.getIndexLocations(IndexSelector.java:319) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.selectIndexURLs(JavaSearchParticipant.java:160) at org.eclipse.jdt.internal.core.search.PatternSearchJob.getIndexes(PatternSearchJob.java:186) at org.eclipse.jdt.internal.core.search.PatternSearchJob.ensureReadyToRun(PatternSearchJob.java:99) at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:262) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:235) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:602) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:670) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:178) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:94) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Repro clues. Seems to occur at the first search after a restart for org.eclipse.ocl.pivot saves as branch ewillink/582053jdt.

org.eclipse.ocl.pivot has Bundle-RequiredExecutionEnvironment: JavaSE-1.8

[iloveeclipse]

I assume your JDT index is broken. Please go to Window -> Preferences -> Java and "Rebuild Index". You will have to wait till all data is reindexed, can take a while depending on how big is your workspace / how fast is your HD.

[ewillink]

Thanks. Must have been very fast - using SSD - nothing on status bar, progress view.

Seems to have fixed the problem.

So residue of bug is an enhancement: a) set a needs-rebuild flag when a problem exception occurs, b) offer a do-you-want-to-rebuild pop-up when an attempt is made to use a broken index.

[ewillink]

Seems to have fixed the problem.

Wow. Magic. import quick fixes even work when the debugger is active. Really do need the semi-self-repairing enhancement.

[iloveeclipse]

I think we don't need to ask user "do you want to rebuild broken index", so ideally we should automatically rebuild it if we encounter such error.

I only wonder why the original authors of that code didn't considered this, it makes no sense to keep running with broken index.

[iloveeclipse]

@gayanper : something you are interested in?

[ewillink]

The format error may be caused by my practice of migrating a workspace backwards and forwards across different Eclipse platform versions.

[iloveeclipse]

I only wonder why the original authors of that code didn't considered this, it makes no sense to keep running with broken index.

Actually they did that! The only place where we don't do that is the place where we read the new metaindex. I will push a PR.

[ewillink]

Yes. But surely the stack trace in the bug report is another use case? If code magically finds another path that bypasses the checks, or if whatever broke the index occurs again, we are running with a broken index. Needs a popup or something to warn the user that a rebuild is needed.

[iloveeclipse]

But surely the stack trace in the bug report is another use case?

Not sure what you mean, the only place is not covered by auto-recovery is the code in question (as far as I can see).

Needs a popup or something to warn the user that a rebuild is needed.

No, it doesn't, same as the other code that did it "silently".

[gayanper]

@gayanper : something you are interested in?

I see you already provided a fix. I have approved it @iloveeclipse

[iloveeclipse]

@gayanper : something you are interested in?

I see you already provided a fix.

While looking on the code I've realized the problem is actually easier as I've initially assumed, since it is just one particular case, not entire index machinery that need to be fixed.

I have approved it

Thanks for quick response!

[ewillink]

Surely my stack trace was a place not covered?

I'm not certain that auto-repair is always appropriate. Consider the, presumably not yet understood, mechanism by which the index breaks. When this occurs, last week nothing happened and usage was degraded. Now you can fix the index, but if fixing repeats the breakage mechanism, an infinite loop could result. A popup ensures that a repair only happens as often as the user requests it. Since the breakage is presumably rare, the popup will be rare and can alert the user that a peek at the error log may provide useful debug information.