microsoft / microsoft/testfx

Race condition between MTP extensions using ITestHostProcessLifetimeHandler

Open
#8,904 7 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area/mtp
Dominant language
C#
Stars
1k
Forks
312
Avg merge
7h 46m
Merged PRs (30d)
465

Description

I'm the author of ReportGenerator which you might be familiar with.
I want to provide a version of ReportGenerator which can be used directly as a MTP extension.
The idea is, that you can use both Coverlet.MTP and ReportGenerator within the MTP platform.
Coverlet collects coverage information and ReportGenerator should generate the corresponding report.

On the command line it would look like this:

dotnet run --project MyProject.csproj --coverlet --reportgenerator

or

dotnet test --coverlet --reportgenerator

Now the problem:
Both Coverlet and ReportGenerator register an out-of-process handler ( ITestHostProcessLifetimeHandler.OnTestHostProcessExitedAsync method).
This is the last method in the execution order (see docs).

On my machine the ReportGenerator handler gets executed before the Coverlet handler. Therefore no coverage files exist (they get generated by Coverlet after ReportGenerator has finished).

Is there a supported way to control ITestHostProcessLifetimeHandler execution order between extensions?
The ReportGenerator handler should be executed after Coverlet.

@Bertk from the Coverlet team suggested to reach out to @Youssef1313.
It would be great if you can take a look.

If required, I can provide a sample repository demonstrating the issue.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with ITestHostProcessLifetimeHandler.OnTestHostProcessExitedAsync and the linked MTP extension execution-order documentation. Reproduce the interaction using the shown Coverlet and ReportGenerator command examples, or the sample repository if provided. Done means identifying whether a supported deterministic ordering mechanism exists and documenting or implementing the agreed behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
testing-qa, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.