[MTP Reporters Analysis] AzureDevOpsReport suppresses failures without a usable local stack frame

[Evangelink]

Summary

AzureDevOpsReport suppresses failures entirely when it cannot resolve a stack frame to a local repo file. The current implementation only emits ##vso[task.logissue ...] when it finds a usable source path; otherwise it silently returns without reporting anything.

Evidence

• src/Platform/Microsoft.Testing.Extensions.AzureDevOpsReport/AzureDevOpsReporter.cs:167-177

  string? line = GetErrorText(testDisplayName, explanation, exception, severity, _fileSystem, _logger, _targetFrameworkMoniker, annotationSuffix);
  if (line is null)
  {
      ...
      return;
  }

• src/Platform/Microsoft.Testing.Extensions.AzureDevOpsReport/AzureDevOpsReporter.cs:193-200

  if (exception is null || exception.StackTrace is null)
  {
      ...
      return null;
  }

• src/Platform/Microsoft.Testing.Extensions.AzureDevOpsReport/AzureDevOpsReporter.cs:274-316

  else
  {
      ...
      continue;
  }
  ...
  if (!fileSystem.ExistFile(fullPath))
  {
      ...
      continue;
  }
  ...
  logger.LogTrace("No stack trace line matched criteria, no failure line was reported.");
  return null;

Why this is a real issue

There are multiple concrete failure shapes that hit this path:

• the framework sets Explanation but no exception,
• an exception exists but has no stack trace,
• stack frames point outside the repo root,
• deterministic/source-generated/external paths do not exist on disk on the current machine.

In all of those cases, the reporter produces no Azure DevOps annotation at all, even though it still has a test display name and an error message that could be logged.

Suggested resolution

Add a fallback task.logissue path that emits at least the message/title when no source location can be resolved. sourcepath / linenumber should be treated as optional enhancements, not as a prerequisite for reporting the failure.

Related issues

• Should output device log issues with Azure syntax when running on Azure? #5979