Error when using Allure with async/await

[VictorYakushenko]

I'm submitting a ...

• bug report
• feature request
• support request => Please do not submit support request here, see note at the top of this template.

What is the current behavior?

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

I get an error when using Allure with async/await

What is the expected behavior?

Allure should works as without async/await

What is the motivation / use case for changing the behavior?

I think using AsyncLocal instead ThreadLocal in stepContext will fix it like in NUnit framework
https://github.com/nunit/nunit/blob/master/src/NUnitFramework/framework/Internal/TestExecutionContext.cs

Please tell us about your environment:

• Allure version: 2.1.0
• Test framework: testng@6.8
• Allure adaptor: allure-testng@2.0-BETA8
• Generate report using: allure-maven@2.18

Other information

[Bakanych]

Hi @VictorYakushenko,
thanks for your feedback. Can you please provide code example which leads to this bug or give a link to demo repo.

[VictorYakushenko]

Hi @VictorYakushenko,
thanks for your feedback. Can you please provide code example which leads to this bug or give a link to demo repo.

Details in #106

[CraigRichards]

I've seen this issue heaps with Async and TestCaseSource. When I run into it again I will put something together.

I'm glad someone has an idea about what might be going wrong. I was stumped myself.

[CraigRichards]

I've tested this patch and it appears to work well in my corporate environment.

I've also included a sample test that puts it through it paces below.

Is there anything stopping this from going through?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Allure.Commons;
using NUnit.Allure.Attributes;
using NUnit.Allure.Core;
using NUnit.Framework;

namespace DeliveryAssured.NUnitSamples.AllureIssues
{
[AllureNUnit]
public class AllureAsyncTest
{
public static IEnumerable TestCaseData() => Enumerable
.Range(1, 1000)
.Select(x => new TestCaseData(x));

    [TestCaseSource(nameof(TestCaseData), Category = "Parallel Bug Hunting")]
    public async Task Test(int iteration)
    {
        var testUser = await GenerateAsync();
        AllureLifecycle.Instance.WrapInStep(() =>
        {
            Assert.AreEqual(testUser, "AAA");
        });
        
        AllureLifecycle.Instance.AddAttachment(
            "Random Attachment",
            "text/plain",
            Encoding.UTF8.GetBytes("Test"),
            ".txt");
    }

    public static async Task<string> GenerateAsync()
    {
        return await Task.Run(() => Generate());
    }

    [AllureStep]
    public static string Generate()
    {
        Thread.Sleep(1000);
        return "AAA";
    }
}

}

[kluiverjh]

Had same problem, AllureLifecycle.Instance.AddAttachment worked until an await statement was used in the nunit test (async nunit test).

As suggested above, replacing ThreadLocal by AsyncLocal solved the problem. (in the allure.common library) The class AsyncLocal is only supported from .net framework 4.6 and above. Didn't do any extensive testing

[evangelos1177]

I've also hit this same issue.
It seems as thought there are 2 outstanding issues on this. There was a PR to fix this a while ago, but it was not merged.
Does anyone know why?

[NaZaRKIN123]

any updates here?

[EvgenyMarchuk]

Do you have any updates here? Who can resolve this issue?

[fonzi]

Having issues with this as well. Breaks with playwright completely.

Edit: I found a workaround for our framework.

[TearDown] is the place where we place the attachments to Allure.
So I just defined as I normally would.

public async Task QED()
{
    screenshot = AppDomain.CurrentDomain.BaseDirectory + "screenshots/screenshot.png"
    await page.ScreenshotAsync(new PageScreenshotOptions { Path = screenshot }); 
}

[TearDown]
public void TearDown()
{
    AllureLifecycle.Instance.AddAttachment("image", "image/png", screenshot );
}

The downside is that I have to call QED() in every test instead of letting TearDown handle it. But otherwise is works.

[Riverlution]

I've just started hitting this issue too - is anyone able to fix it soon?

[vladdex]

Because of this error using Allure in any Playwright test suite is impossible, all playwright methods are async so you have to call all your test methods using await which causes this error.
Is there any chance that this will be looked at soon ?

[neparij]

Hello everyone!
Should be fixed in upcoming preview release with changes authored by @overlord
I'll write as soon as I upload it.

[neparij]

2.9.4-preview.1 package

[undron]

Hello, here is another unstable behavior using 2.9.4-preview.1 Try this code:

        [Test]
        [Repeat(5)]
        public void Test1()
        {
            SyncStep();
        }
        
        [AllureStep("Sync step")]
        public object SyncStep()
        {
            return GetAsync<object>().Result;
        }
        
        [AllureStep("Return object")]
        public async Task<T> GetAsync<T>() where T: new()
        {
            await Task.Delay(10);
            return new T();
        }

I understand that this is bad practice, but...

[overlord]

@undron, try Allure.NUnit 2.9.4-preview.6 - there was another fix on this issue.

[undron]

@overlord All seems good now

[sphinxy]

Same issue exists in Xunit, any plan or simple way to fix it?

[delatrie]

Hi, @sphinxy and everyone!
We've put a lot of effort into making all integrations concurrency-friendly. In the recent 2.10.0 version of both Allure.XUnit and Allure.NUnit all those annoying async-related bugs should be fixed. Try it!

If the issue still exists, please, let me know here.