🐛 Плавающая ошибка при взаимодействии с шиной данных

[picolino]

Шаги воспроизведения

• Вызвать функционал, в котором существует публикация сообщений в шину событий.
• Повторить вызов этого же функционала
• Вы получите следующую ошибку:

        "message": "Cannot access a disposed object.\r\nObject name: 'IServiceProvider'.",
        "stackTrace": "   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ThrowHelper.ThrowObjectDisposedException()\r\n   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope.GetService(Type serviceType)\r\n   at SlimMessageBus.Host.Collections.GenericTypeCache`1.ResolveAll(IServiceProvider scope, Type messageType)\r\n   at SlimMessageBus.Host.MessageBusBase.ProducePublish(Object message, String path, IDictionary`2 headers, IServiceProvider currentServiceProvider, CancellationToken cancellationToken)\r\n   at SlimMessageBus.Host.Hybrid.HybridMessageBus.ProducePublish(Object message, String path, IDictionary`2 headers, IServiceProvider currentServiceProvider, CancellationToken cancellationToken)\r\n   at Garnet.Common.Infrastructure.MessageBus.SlimMessageBus.Publish[TMessage](TMessage message) in D:\\garnet-team\\common\\server\\Garnet.Common.Infrastructure\\MessageBus\\SlimMessageBus.cs:line 16\r\n   at Garnet.Teams.Application.Team.Commands.TeamCreateCommand.Execute(CancellationToken ct, TeamCreateArgs args) in D:\\garnet-team\\features\\team\\server\\Garnet.Teams.Application\\Team\\Commands\\TeamCreateCommand.cs:line 41\r\n   at Garnet.Teams.Infrastructure.Api.TeamsMutation.TeamCreate(CancellationToken ct, ClaimsPrincipal claims, TeamCreateInput input) in D:\\garnet-team\\features\\team\\server\\Garnet.Teams.Infrastructure\\Api\\TeamsMutation.cs:line 64\r\n   at HotChocolate.Resolvers.Expressions.ExpressionHelper.AwaitTaskHelper[T](Task`1 task)\r\n   at HotChocolate.Types.Helpers.FieldMiddlewareCompiler.<>c__DisplayClass9_0.<<CreateResolverMiddleware>b__0>d.MoveNext()\r\n--- End of stack trace from previous location ---\r\n   at HotChocolate.Types.MutationConventionTypeInterceptor.<>c__DisplayClass16_0.<<ApplyResultMiddleware>b__1>d.MoveNext()\r\n--- End of stack trace from previous location ---\r\n   at HotChocolate.Execution.Processing.Tasks.ResolverTask.ExecuteResolverPipelineAsync(CancellationToken cancellationToken)\r\n   at HotChocolate.Execution.Processing.Tasks.ResolverTask.TryExecuteAsync(CancellationToken cancellationToken)"

Ожидаемое поведение

Ошибки быть не должно

Дополнительная информация

На первый взгляд кажется, что ошибка связана с тем, что по-умолчанию SlimMessageBus (внешняя библиотека, используемая в качестве реализации шины сообщений) при общении в памяти блокирует вызов до момента обработки сообщения консьюмером:

https://github.com/zarusz/SlimMessageBus/blob/master/docs/provider_memory.md#blocking-publish

То есть, когда мы отправляем сообщение в шину, она дожидается его обработки консьюмером, а затем продолжает выполнение кода.

Плюс ко всему, по-умолчанию консьюмеры в шине сообщений регистрируются как Singleton, и мы получаем captive-dependencies (когда Singleton-объект зависит от Scoped-объектов):

https://github.com/zarusz/SlimMessageBus/blob/master/docs/provider_memory.md#per-message-di-scope

Ошибка, описанная выше, вполне себе может быть следствием этих настроек.

[picolino]

Причины возникновения ошибки

Исходная проблема крылась в комплексной несовместимости нашего DI, DI библиотеки HotChocolate и библиотеки slimMessageBus. Дело в том, что HotChocolate, хоть и интегрирован в стандартный Microsoft DI, но использует свои резолверы для того, чтобы обеспечивать полную работоспособность функционала, поставляемого вместе с их библиотекой.

Они приверженцы подхода прокидывать зависимости не через конструктор (как это делаем мы), а через параметры методов: https://chillicream.com/docs/hotchocolate/v12/server/dependency-injection В связи с этим архитектурным решением они регистрируют все свои типы, относящиеся к API GraphQL как Singleton'ы и возможности переопределить это поведение у нас просто нет.

Такая жесткая привязка к регистрации точек входа как Singleton вызывает в библиотеке SlimMessageBus определенный сбой. Эта библиотека создает новый Scope на каждый отправляемый Message в шину. А после обработки сообщения производит его очистку (Dispose). Но из-за того что точка входа у нас зарегистрирована как Singleton, при следующей отправке и обработке сообщения библиотека SlimMessageBus возьмет уже существующий скоуп (который уже очищен), а не создаст новый. Это и приводило к ошибке.

Решение простое. Мы максимально ограничиваем использование DI контейнера Hot Chocolate. Все типы регистрируем в стандартном DI контейнере и делаем их Scoped. Это позволит нам использовать полноценную иньекцию через конструктор (даже текущего авторизованного пользователя), а также избавит от проблем с Singleton-зависимостями.

Но для этого придется много чего перелопатить...