"SqlException: The transaction operation cannot be performed because there are pending requests..." during setup with SQL Server #15794
Comments
|
This maybe related to #15628 |
|
An unhandled exception occurred while processing the request. |
|
An unhandled exception occurred while processing the request. |
|
An unhandled exception occurred while processing the request. |
|
just met the above 3 errors when i keep the old volume of the db use the same ways, i did not met the errors using the commit of a long time ago |
|
Hmm, we actually have quite a lot of |
|
@Piedone yes I agree with your assessment. Recipes and sub recipes are executed in a new tenant scope and should be using a new instance of the ISession. Maybe there is an issue with creating a new scope where we are reusing same service across scope |
|
Hmm, do we need new scopes, to begin with? Is that for when recipes enable/disable features, right? If this is done before #15628 (if the two are different issues, to begin with; I'm not sure) then here also we should also change the trigger of on:
# Manual trigger.
workflow_dispatch:
pull_request_review:
types: [submitted] |
We mainly use
When we execute sub recipes from a main recipe, each recipe should run independently with a new scope. I am guessing there is a reason why it's done this way but not sure I know the exact reason. |
|
Yeah, I guess that's to allow reloading the shell for feature state changes. |
Piedone
changed the title
|
The issue here is related to UpdateRole It is what is causing this issue. It has to be a concurrency issue because if you step through the code everything works. |
|
If this is something that stopped working, maybe going back in time could help isolate the problem to a few commits? My instinct would say it's about the |
|
Yeah very strange. I tried to locate all files that are involved and looking at their change history. I don't see anything that stood out. Unless there is an issue with the shell scope. I don't recall seeing any change in the infrastructure. But assigning an incorrect current scope could cause this odd behavior |
This was referenced May 1, 2024
|
@sebastienros I think I see the problem now. But I am still not sure what changes for this to break now and work before. The method RoleUpdater.UpdateRolesForInstalledFeatureAsync is called when the features are installed and this is called using a deferred task. Next, the RoleStep "which is executed during the setup" uses the RoleManager to create or update roles. When the role manager is called, the Since the RoleUpdater and The RoleStep both call the DocumentManager, this seems to be causing the issue. To confirm the finding, I removed the |
|
Isn't this called by chance, parallelizing steps? Or, perhaps, isn't one of the services resolved or reused across scope boundaries? |
|
@Piedone this is only called by ModularBackgroundService and in OrchardCore/src/OrchardCore/OrchardCore/Extensions/ExtensionManager.cs Lines 301 to 324 in 7bff0b9 |
|
I think I have a good theory about what is happening. I'll try it out tomorrow. |
|
If that helps, I test locally by setting up the autosetup module in appsettings.json // WARNING: AutoSetup section given as an example for Development only, for Production use "Environment Variables" instead
"OrchardCore_AutoSetup": {
"AutoSetupPath": "",
"Tenants": [
{
"ShellName": "Default",
"SiteName": "AutoSetup Example",
"SiteTimeZone": "Europe/Amsterdam",
"AdminUsername": "admin",
"AdminEmail": "info@orchardproject.net",
"AdminPassword": "Demo123!",
"DatabaseProvider": "SqlConnection",
"DatabaseConnectionString": "Server=localhost;Database=tempdb;User Id=sa;Password=Password12!;TrustServerCertificate=True",
"DatabaseTablePrefix": "test39",
"DatabaseSchema": "",
"RecipeName": "Blog"
},This way I only need to start the app with the changes and update the DatabaseTablePrefix to see it crashing. Besides I also have changed my local yessql projects to detect concurrent usages of sessions (read or writes) and show both stacktraces when this happens. Maybe something to add as an option in yessql for later occurences, the same way DI has this options to let us know when a Singleton resolves a Scoped. |
|
These are the two concurrent stacktraces that trigger the issue consistently for me (now even with my changes, I assume it worked once and didn't recrete the tenant after) One thread is saving a document in |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
To Reproduce
Steps to reproduce the behavior:
Expected behavior
There should be no exceptions
Screenshots
The text was updated successfully, but these errors were encountered: