GraphQL failed to retrieve more than one type in single request

[AndreySurkov]

Describe the bug

When request more than one GraphQL command that require DB aceess they execute in parellel and result wih error.

GraphQL.Execution.UnhandledError: Error trying to resolve field 'typeA'.
 ---> Npgsql.NpgsqlOperationInProgressException (0x80004005): A command is already in progress: SELECT \"Document\".* FROM \"Document\" INNER JOIN (SELECT \"Document\".\"Id\", MAX(\"ContentItemIndex_a1\".\"CreatedUtc\") AS \"order_1\" FROM \"Document\" INNER JOIN \"ContentItemIndex\" AS \"ContentItemIndex_a1\" ON \"ContentItemIndex_a1\".\"DocumentId\" = \"Document\".\"Id\" WHERE \"Document\".\"Type\" = @Type AND  ((\"ContentItemIndex_a1\".\"Published\" = @p1) AND (\"ContentItemIndex_a1\".\"ContentType\" = @p2)) GROUP BY \"Document\".\"Id\" ORDER BY \"order_1\" DESC limit 100) AS \"IndexQuery\" ON \"IndexQuery\".\"Id\" = \"Document\".\"Id\" ORDER BY \"order_1\" DESC
   at Npgsql.ThrowHelper.ThrowNpgsqlOperationInProgressException(NpgsqlCommand command)
   at Npgsql.Internal.NpgsqlConnector.<StartUserAction>g__DoStartUserAction|279_0(ConnectorState newState, NpgsqlCommand command, CancellationToken cancellationToken, Boolean attemptPgCancellation)
   at Npgsql.NpgsqlCommand.ExecuteReader(Boolean async, CommandBehavior behavior, CancellationToken cancellationToken)
   at Npgsql.NpgsqlCommand.ExecuteReader(Boolean async, CommandBehavior behavior, CancellationToken cancellationToken)
   at Npgsql.NpgsqlCommand.ExecuteDbDataReaderAsync(CommandBehavior behavior, CancellationToken cancellationToken)
   at Dapper.SqlMapper.QueryAsync[T](IDbConnection cnn, Type effectiveType, CommandDefinition command) in /_/Dapper/SqlMapper.Async.cs:line 434
   at YesSql.Store.<>c__DisplayClass44_0`2.<<ProduceAwaitedAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at YesSql.Data.WorkDispatcher`2.ScheduleAsync[TState](TKey key, TState state, Func`3 valueFactory)
   at YesSql.Store.ProduceAwaitedAsync[T,TState](WorkerQueryKey key, Func`3 work, TState state)
   at YesSql.Services.DefaultQuery.Query`1.ListImpl()
   at YesSql.Services.DefaultQuery.Query`1.ListImpl()
   at OrchardCore.ContentManagement.GraphQL.Queries.ContentItemsFieldType.ResolveAsync(IResolveFieldContext context) in C:\\Repo\\GitHub\\OrchardCore\\src\\OrchardCore\\OrchardCore.ContentManagement.GraphQL\\Queries\\ContentItemsFieldType.cs:line 116
   at GraphQL.Resolvers.FuncFieldResolver`1.<>c__DisplayClass2_0.<<-ctor>b__0>d.MoveNext() in /_/src/GraphQL/Resolvers/FuncFieldResolver.cs:line 36
--- End of stack trace from previous location ---
   at GraphQL.Execution.ExecutionStrategy.ExecuteNodeAsync(ExecutionContext context, ExecutionNode node) in /_/src/GraphQL/Execution/ExecutionStrategy.cs:line 516
   --- End of inner exception stack trace ---

Orchard Core version

2.1.0

To Reproduce

1. Instantiate new Orchard Site using PostgreSQL
2. Enable Content Types and GraphQL features
3. Create two types (TypeA and TypeB for example)
4. Go to GraphQL and execute request

 query MyQuery {
  typeB {
    displayText
  }
  typeA {
    displayText
  }
}

Logs and screenshots

Seems like during migration on GrapgQL v7 LockedAsyncFieldResolver was incorrectly refactored.
Method LockedAsyncFieldResolver was marked as 'new' and does not execute.

https://github.com/OrchardCMS/OrchardCore/blob/d8168f2cf03b7c986e757aaaa8b060a255eb8c5b/src/OrchardCore/OrchardCore.Apis.GraphQL.Abstractions/Resolvers/LockedAsyncFieldResolver.cs#L13C42-L13C43

[github-actions]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

[HazNut]

I'm also seeing a similar issue when running SQL Server, and for 2.1.3, but with different exceptions. We updated to the latest release recently and it seems to have broken some of our queries, so a pretty major issue :(

Some of the exception messages I've seen are:
There is already an open DataReader associated with this Connection which must be closed first.

The connection does not support MultipleActiveResultSets.

BeginExecuteReader requires an open and available Connection. The connection's current state is connecting.

If I enable EnableThreadSafetyChecks for YesSql in my appsettings, I get this instead:
Two concurrent threads have been detected accessing the same ISession instance.

What's the best way to work around this for now? Downgrade to pre-2.1.0, or maybe enable MultipleActiveResultSets on the connection string?

[AndreySurkov]

Hi, I created PR that fixes this issue but I'm curious if It can be included in next 2.x release (if it planned) because this is regress of 2.1 version agains 1.8 that blocks migration of our project.