Build fails with "Unable to process incoming event 'ProgressComplete ' (ProgressCompleteEvent)"


(Niklas Walter) #1

Since we have updated our gradle version to 2.14 on some of our developer machines (win7 x64) the builds of our multi-project-build fail unpredictable with the following exception:

FAILURE: Build failed with an exception.

* What went wrong:
Unable to process incoming event 'ProgressComplete ' (ProgressCompleteEvent)

Unfortunately when we rerun the build with -s it finishes successful.

mutli-project with parallel execution
<!-- Please fill in the answers below to make it easier for us to answer your question. -->
**Gradle Version:**  

**Operating System:**
Windows 7 64 bit
Oracle JDK 7
CMD-Batch and Git-Bash 

**Is this a regression? If yes, which version of Gradle do you know it last worked for?**
Yes, worked on 2.12

<!-- Please include a link to an example project if you have one -->
<!-- Please include a link to a build scan if you have one -->

(Paul Merlin) #2

Hi Niklas,

Thanks for the report!
Could you please try to produce a build scan ?
That should record the failure details and give us insights into what is happening.

(Niklas Walter) #3

Thank you for your reply.

I have produced a build scan of our build
As the problem occurs not deterministic I’m a little bit in trouble to produce a scan of a failing build but I will try my best.

(Niklas Walter) #4

It seems that I’m not able to reproduce the failure with scan enabled.
In the mean time I’ve done some researches on my own.
It seems like the problem is just in the console output.
The daemon log of the failed builds are completely okay and seems like the build continues after the command line outputs “FAILURE: Build failed with an exception.”

(Paul Merlin) #5

Hum I see. It may prove impossible to track down without being able to reproduce.
Any chance you could either share your build or isolate the issue in a small build?

(Paul Shaw) #6

I can give you a little insight into this, as we had exactly the same thing and I was able to solve it.

The problem we had was some input and output directories for a task incorrectly initialised to directories that didn’t exist. Within another plugin these incorrect values were reset to the correct values. The fix for us was to correct this incorrect initial setting.

Locally devs are using the daemon and configuration on demand and we only ever saw this problem locally and not on our build agents which do not use the daemon. I am guessing that the issue is around the daemon causing this error when attempting to store the snapshot of the inputs and/or outputs in the scenario where it is still using the incorrect value.

I do not have time at the minute to recreate this in a simple build. Hope this helps.

(Niklas Walter) #7

Luckily I was able to get a scan of a build that crashed with the stated exception
As you can see in the scan, the daemon finished the build successfully.

(Paul Merlin) #8


Thanks for the build scan.
But I don’t get why you say it crashed and succeeded at the same time.
The scan shows a working build.
Am I right assuming this is a successful scan of the very build you saw failing but couldn’t reproduce?

(Niklas Walter) #9

Hi Paul,

this is the strange thing that happens. As you can see in the build scan, the build succeeded, that is what daemon log although says. The message on the command line, the user got was:

FAILURE: Build failed with an exception.

  • What went wrong:
    Unable to process incoming event 'ProgressComplete ’ (ProgressCompleteEvent)

(Paul Merlin) #10

Could you give it a try with the latest nightly?
It includes some fixes around build events fired twice.

If you still see these errors we’ll investigate further.


(Anatol Bollinger) #11

Hi Paul.

I’m experiencing the same issue, also with the nightly build you linked.
The only permanent fix seems to be downgrading gradle (currently to 2.11).

single-project, no parallel execution, using gradle-node-plugin

Gradle Version:

Operating System:
Windows 7 64 bit
Oracle JDK 8

Is this a regression? If yes, which version of Gradle do you know it last worked for?
Yes, worked on 2.11

Thanks for your help,

(Paul Merlin) #12

Niklas, Paul, Anatol,

So there’s something else going on here.
Unfortunately it’s going to be practically impossible to diagnose without more detail.

This issue is sporadic. Our guess is that it hasn’t happened yet with -s or -Dscan enabled.
I have no idea of how many times you actually tried.
You could enable one or the other for all your build invocations so we get a better chance at seeing the stacktrace.

Or, any chance that one of you can share his build so I can reproduce the issue locally ? (feel free to PM me)

(Niklas Walter) #13

Hey Paul,

as mentioned earlier, the scan uploaded by me has failed on the command line.
We now also running all of our builds with a hard wired -s parameter in the start script.
The problem still occurs but we don’t get any stacktraces although we have set the -s parameter.

As stated earlier the daemon finishes the build successful although the command line states an other result. I’ve uploaded a log from a build that shows this. The archive includes the commandline output (cmd.txt) and the corresponding log from the daemon (daemon-6148.out.log). (15.3 KB)

Unfortunatly we were not able to try the latest nightly so far as we had some other problems with running it on our project.

(Paul Merlin) #14


Thanks Niklas for the clarification and sorry for the delay, I took some time off.
Reading that thread again I guess I needed it :slight_smile:

We made some changes to how console rendering is done in 2.13.
I’ll take a deeper look and follow up.

@nwalter, you said that downgrading to 2.12 solved your issue.
@anatolb, you said you had to downgrade to 2.11, can you confirm that 2.12 does not work for you?

(Anatol Bollinger) #15

Hi Paul.

Version 2.11 was just a version easily available in our local repository , for all I know 2.12 would have worked as well.

Thanks a lot for your help.


(Paul Merlin) #16

Thanks, just filled GRADLE-3527.

(Gordon Wallace) #17

Some of my team was using git 1.9.4 and the associated git-bash console. This error occurred in their build

I use git 2.6.2 and its associated git-bash console. This error does not occur in my build.

Some team members use the DOS command line. The error occurs in their build.

I use a DOS command line, but I always configure it for a 1024/1024 buffer size. The error does not occur for me there.

(I am the author of a fresh new build at my company and apparently my computer was magically set up to work… Not the best when the team goes to adopt the new process and I have no idea what’s happening to them!) :confounded:

There’s some curious interaction between Gradle and the output stream to the console…

The Workaround:

use the –console plain gradle command line switch

The Fix:

If you use git + git-bash, upgrade to git 2.x.x (2.9.3 is current and works for me)

If you use DOS, try increasing your screen buffer size.(mine is 1024 x 1024)

this information was also added to GRADLE-3527

(Julian Hall) #18

Thank you @gordwilling !!

I have been fighting with random silent failures for a wile after I upgraded to v 2.13.
It seems for me when I have sequential Exec gradle tasks run - it will fail silently.
Adding the --console plain does the trick!

The console output from the Exec tasks seems to be missing now, but it still works.

(Gordon Wallace) #19

Glad it worked for you! It’s my first time posting anything useful so you’ve made me happy :slight_smile:

(Klaus Christiansen) #20

Bonus info:
This problem also occur in 3.0
–stacktrace produces nothing. :frowning:
–info solves nothing. :frowning:
–debug also leads to SUCCESS. :slight_smile: