Intermittant blocked calls

• Abp package version: NuGet 4.1.0
• Base framework: targetting .Net Framework 4.7.2 / .Net Core 2.2.1
• Exception message: N/A
• Stack trace: I only have a screenshot, I’m not able to reliably repro but I’ll get a text stack trace next time.
• Steps needed to reproduce the problem: The problem is intermittent and has only been reproduced (randomly) in a development environment a handful of times. In our Test Environment, the issue occurs ~3 times a day (24 hrs).
• Issue definition:

1. Seemingly randomly calls that are made to AbpUserConfiguration.GetAll() will never complete, it appears that the request never completes possibly due to a thread/table lock.
2. I copied the AbpUserConfigurationBuilder class to our code-base to better try and debug the issue. Luckily I was able to replicate the issue locally I got to a point where I found calls to var languages = LanguageManager.GetLanguages(); became blocked (see screenshot).
3. Once the code-base gets itself into this state ALL calls to the UserConfiguration will block and never complete. It’s as though a mutex/lock has occurred. At first, I thought the issue would be limited to a single user but this is not the case, all calls to this endpoint whether logged in or not will fail.
4. It appears that somewhere within the GetLanguage call the AsyncEx.Run call becomes blocked forever.
5. There’s no exception raised at runtime or in the log file.
6. The threads never appear to end, as I make subsequent calls to the endpoint I can see the existing threads in the Threads panel.

The issue has been seen in development environment (Windows 10, VS2017), Azure AppService, self-hosted (Windows server 2016).

Please, I’m seeking assistance/help/guidance at the possible root cause here? Without a reliable way to repro the issue I understand it’s a tough issue to crack - please let me know if there’s any other info I can attempt o retrive. The only workaround we have at the moment is recycling the IIS Application pool.

[Mozketo]

AspNet RAD tool shows as 1.8.0.2 in VS2017 Zero version 6.6.0 as shown in Zero download page.

• The AppService that introduced the L usage was our very first service written in late Sep-2018, at the time we were using ObjectMapper but later switched to manually returning a DTO bypassing ObjectMapper.
• Later in the year, we started to return a string value for the enum as the endpoint was being consumed by a ReactNative mobile application.
• The introduction of L("") was introduced by a developer to solve a problem, we didn’t know the potential impact. Moving forward we’ll be sure not to reuse this pattern.

I’m quite confident that the L("") within the EF query causes our random lockups. We’re now in day 4.5 and Dev-env and QA-env have not had a single lockup. We used to see at least 3 app-pool recycles a day.

I’m still wary that it may manifest in some other way such as @jmhinnen is seeing. I will close this ticket for now.

[ismcagdas]

@AlexHikeK according to our investigation, AspNet Zero’s RAD Tool never generated such a code, so we haven’t done anything related to this in RAD Tool.