Error: Unable to get code coverage data within the maximum wait time.

[aapalm]

We seem to run into this issue a lot during our VSTS builds... Is there any way to increase the wait time? And could it be possible to make this type of issue a non-blocking issue?

Logs 2018-05-16T21:49:58.7248298Z ##[section]Starting: Check build quality 2018-05-16T21:49:58.7255594Z ============================================================================== 2018-05-16T21:49:58.7255782Z Task : Build Quality Checks 2018-05-16T21:49:58.7255924Z Description : Breaks a build based on quality metrics like number of warnings or code coverage. 2018-05-16T21:49:58.7256078Z Version : 4.0.3 2018-05-16T21:49:58.7256193Z Author : Microsoft Premier Services 2018-05-16T21:49:58.7256343Z Help : [[Docs]](https://github.com/MicrosoftPremier/VstsExtensions/blob/master/BuildQualityChecks/en-US/overview.md) 2018-05-16T21:49:58.7256498Z ============================================================================== 2018-05-16T21:49:59.4129650Z SystemVssConnection exists true 2018-05-16T21:50:00.2650661Z Validating code coverage policy... 2018-05-16T21:50:00.9387105Z Waiting for code coverage data... 2018-05-16T21:50:03.2456684Z Waiting for code coverage data... 2018-05-16T21:50:05.6504725Z Waiting for code coverage data... 2018-05-16T21:50:08.0178902Z Waiting for code coverage data... 2018-05-16T21:50:10.4259277Z Waiting for code coverage data... 2018-05-16T21:50:13.3572820Z Waiting for code coverage data... 2018-05-16T21:50:15.7787340Z Waiting for code coverage data... 2018-05-16T21:50:18.1397531Z Waiting for code coverage data... 2018-05-16T21:50:20.7485503Z Waiting for code coverage data... 2018-05-16T21:50:23.4266950Z Waiting for code coverage data... 2018-05-16T21:50:26.2908528Z Waiting for code coverage data... 2018-05-16T21:50:29.2558726Z Waiting for code coverage data... 2018-05-16T21:50:31.9435923Z Waiting for code coverage data... 2018-05-16T21:50:34.4656447Z Waiting for code coverage data... 2018-05-16T21:50:36.9878342Z Waiting for code coverage data... 2018-05-16T21:50:39.3039062Z Waiting for code coverage data... 2018-05-16T21:50:41.6480561Z Waiting for code coverage data... 2018-05-16T21:50:43.9161386Z Waiting for code coverage data... 2018-05-16T21:50:46.1988572Z Waiting for code coverage data... 2018-05-16T21:50:48.6287829Z Waiting for code coverage data... 2018-05-16T21:50:50.9094342Z Waiting for code coverage data... 2018-05-16T21:50:53.2775045Z Waiting for code coverage data... 2018-05-16T21:50:55.5448627Z Waiting for code coverage data... 2018-05-16T21:50:57.8574853Z Waiting for code coverage data... 2018-05-16T21:51:00.2773540Z Unable to get code coverage data within the maximum wait time. 2018-05-16T21:51:00.2818408Z Total blocks: 0 2018-05-16T21:51:00.2833050Z Covered blocks: 0 2018-05-16T21:51:00.2833727Z Code Coverage (%): 0 2018-05-16T21:51:00.3677537Z Waiting for code coverage data... 2018-05-16T21:51:00.5464566Z Found baseline build with ID 9773695. 2018-05-16T21:51:00.9463879Z Successfully read code coverage data from build. 2018-05-16T21:51:00.9476711Z Total blocks: 349080 2018-05-16T21:51:00.9477598Z Covered blocks: 82115 2018-05-16T21:51:00.9478422Z Code Coverage (%): 23.52 2018-05-16T21:51:00.9556607Z ##[error]At least one build quality policy was violated. See Build Quality Checks section for more details. 2018-05-16T21:51:02.8166985Z Waiting for code coverage data... 2018-05-16T21:51:05.3562323Z Waiting for code coverage data... 2018-05-16T21:51:08.2791315Z Waiting for code coverage data... 2018-05-16T21:51:10.6545942Z Waiting for code coverage data... 2018-05-16T21:51:13.0335881Z Waiting for code coverage data... 2018-05-16T21:51:15.4150198Z Waiting for code coverage data... 2018-05-16T21:51:17.7266073Z Waiting for code coverage data... 2018-05-16T21:51:20.0402328Z Waiting for code coverage data... 2018-05-16T21:51:22.3371444Z Waiting for code coverage data... 2018-05-16T21:51:24.7008607Z Waiting for code coverage data... 2018-05-16T21:51:27.2342584Z Waiting for code coverage data... 2018-05-16T21:51:29.7517659Z Waiting for code coverage data... 2018-05-16T21:51:32.0729564Z Waiting for code coverage data... 2018-05-16T21:51:34.3929544Z Waiting for code coverage data... 2018-05-16T21:51:36.6814670Z Waiting for code coverage data... 2018-05-16T21:51:39.2285325Z Waiting for code coverage data... 2018-05-16T21:51:41.9763034Z Successfully read code coverage data from build. 2018-05-16T21:51:41.9861993Z ##[section]Finishing: Check build quality

[almtcger]

Hi Aaron,

we're actually preparing documentation for this. Until it is done and officially available, this should help you:

Q: I am getting "Unable to get code coverage data within the maximum wait time". What's wrong? A: Code coverage data is processed asynchronously by the build agent and Team Foundation Server/Visual Studio Team Services. Therefore, the policy has to wait for the data to be available and stable (see next question) before it can check coverage values. If processing code coverage data takes longer than the default wait time of one minute, the task policy gives up and assumes there is no code coverage available in the current build. If you encounter this situation and you have verified that there is code coverage data for your build, try setting the variable PSGer.Cover.MaxWaitTime to a higher wait time in milliseconds (e.g., 120,000 = two minutes) to allow the policy to wait longer.

[aapalm]

Thanks @almtcger, will give it a try

[messinadan]

I am getting this error as well and know there are code coverage results, in fact the build summary page is reporting them. I'm using TFS 2018 on premises, I'm not so sure waiting longer is the issue because the console reports the code coverage step is complete before the quality check task. It is worth a try however, how do I set the PSGer.Cover.MaxWaitTime variable?

[almtcger]

Hey there,

even if the publish code coverage or the VS test task has finished, code coverage data may still be processed in the background. The tasks only trigger the upload of data, but the actual upload is done asynchronously by the build agent. In addition, even if the upload to TFS or VSTS has finished, code coverage data needs to be processed on the server before our task can read the data.

Unfortunately, there is no API that allows a task to deterministically wait for that processing. Thus, we try to read the data over and over again until we either see stable data or assume that code coverage is missing. Thus, increasing the wait time should always solve this problem.

You can set the variable like any other build variable in the variable tab page of your build definition. Just use PSGer.Cover.MaxWaitTime as the variable name and set the value to 120000 (= two minutes).

If this doesn't help, please run your build again with the variables System.Debug and BQC.LogRawData set to true and send us the task log via email to PSGerExtSupport@microsoft.com. This log should help us find the root cause for your issue.

Hope that helps, René

[messinadan]

very helpful, thanks. I set the variable as you said and the build worked however it finished very quickly, < 10 secs after the test task finished so I tried the build again with a value of 60000. Again the build finished correctly very quickly. A third try without the variable finished as well correctly identifying a code coverage violation < quota set. Your task worked flawlessly so I'm not sure what the issue was on the first run where the build failed with a timeout but things are working correctly now. This task is exactly what we need to keep our unit test coverage high. Thanks for the fast feedback

[almtcger]

@messinadan: What you describe is exactly the "problem" with the asynchronous data processing. In most cases the data should be available within our default wait time of one minute. However, sometimes either the build infrastructure, build machine or TFS/VSTS are slower and it takes a bit more time. Since multiple of our customers seem to be running into this sporadically, I think we should increase our default wait time to two minutes. This doesn't hurt at all, because the task will finishe as soon as it got the code coverage data.

@aapalm: I'm going to close this issue now as I believe your problem was fixed as well.

If you have any additional questions or feedback, feel free to open another issue, send us an email, or use the rating or Q&A sections on the Visual Studio marketplace.

Thanks and happy building! René

[HfCpx]

We're using TFS 2018 Update 3 and are having the same issue with some of our build agents. With one kind of agents (Windows Server 2012, having a lot of additional stuff installed like Visual Studio 2017 and third-party software), if works without any problem (takes about 5 seconds to get the code coverage results), with the other kind of agents (Windows Server 2016, having only .NET 4.6.1 installed, nothing else), even changing the timeout to 15 minutes doesn't help. Both agent types are using the latest agent version for TFS 2018 Update 3 and are using the same project/build.

[ReneSchumacher]

Hey,

do you see code coverage values in the build summary? The task itself does not calculate code coverage so you have to make sure that the tool you use to run your tests creates coverage data and that you publish it correctly to your Team Foundation Server. Unless your build summary page displays the coverage values our task cannot evaluate it.

René