Sporadic test failure in LocalAppEnginePublishOperationTest #1798
Comments
|
I can confirm this is not new. I have seen this occasionally (quite infrequently fortunately) for a very long time. |
|
Failing in the same test class but at a slightly different location: The class file |
|
Got another interesting error: |
|
Hit again (full log) on Neon. I wonder if there's a pending operation happening here. |
|
So we get errors at various stages:
We know |
|
Maybe call |
|
Seen on the Java 7/Mars build: |
|
Another one: |
|
I wonder if there's another project with an error that is somehow being picked up. |
|
Just saw this one again on Travis: |
|
Comparing the output with #2682 (comment), the |
|
Hit this twice today, once on Travis and once on Kokoro Windows (!): |
|
Another failure on Travis with Oxygen: |
|
About the above failure, I can reproduce it if I turn off the auto-building before importing the projects. public void setUp() throws IOException, CoreException, InterruptedException {
// disable auto-building
IWorkspace workspace = ResourcesPlugin.getWorkspace();
IWorkspaceDescription desc = workspace.getDescription();
desc.setAutoBuilding(false);
workspace.setDescription(desc);
projects = ProjectUtils.importProjects(getClass(),It may be that the publish is done before the project is fully built. I think the fact that the following assertions on static files that preceded the failure are OK supports this. assertTrue(new File(webInf, "appengine-web.xml").isFile());
assertTrue(new File(webInf, "web.xml").isFile());
assertTrue(new File(webInf, "classes/sox/server/GreetingServiceImpl.class").isFile());What is weird is that, |
|
Indeed, my suspicion was right. It just hit the debug code from #2917, proving that a Now that we know the root cause, we're close to finally close this issue. I think for this flakiness, we will just wait in a loop until the classes we are interested in are generated. And we shouldn't forget that |
|
Make sure to remove the diagnostic code before closing this issue. |
|
I hit a similar issue with #2914 and realized that I had written a job that had no |
|
LocalAppEnginePublishOperationTest-sharedModule-null.txt Just hit the error that |
|
We should add a comment to |
|
There's something deeper going on as the build should have finished after 22s. I wonder if this is the same problem causing issues with #1529, which I believe was fixed by Eclipse bug 478634 and committed to Oxygen.3. I see our .target is still against .2 so I'll re-generate the .target against .3 and resubmit #1529 and lets see if this problem recurs. |
|
Note that there are three separate issues mixed in this one GitHub issue (#1798 (comment)). I feel that the build error issue and the publish-before-build error have been taken care of. The module loading issue is what we continue to hit, even after we give 10 more seconds to Eclipse (#2917). I feel Eclipse fails to initialize or load modules. One option as a last resort could be to delete the projects and re-import if this happens? |
|
So, there remains one last flaky behavior with this test. There is an error marker that never goes away after importing the project. At the 4-minute mark: I wonder what the error(s) are. That said, if (checkBuildErrors) {
waitUntilNoBuildErrors();
// changed from specific projects to see all possible errors
failIfBuildErrors("Imported projects have errors");
}It should have a |
|
Finally, #3117 reveals the error that is causing |
|
Maybe refreshing Another potentially better approach would be to import |
|
The workspace should do a rebuild once |
|
"waitUntilNoBuildErrors" and "failIfBuildErrors" both wait for and check any errors in the workspace, and this error was the only one reported. Note After all, I think it's more robust to open the projects one by one. |
|
I've been importing multiple projects at a time for years using the Import Existing Projects wizard and never seen this issue. I'm more inclined to requesting a clean build. |
|
I don't doubt the import wizard fails to create and open projects. I'm theorizing that when one of the projects being opened depends on another project in the open set, the build system may somehow fail to either recognize the dependent project becoming available, trigger a rebuild, or refresh it. After all, it is clearly a bug that the false error doesn't go away for 5 minutes. |
Test failure on Java 7 with Mars. Failing code attempts to obtain the WTP
IModulefor the shared project:Nothing interesting on the transcript:
The text was updated successfully, but these errors were encountered: