Wolverine como sucessor do MediatR

A regra do roteiro — "talvez, com mais tempo" conta como não — foi aplicada literalmente. Nenhum teste de tenancy foi editado: a única alteração em arquivo de teste foi na fábrica de composição (TestWebApplicationFactory), atrás de uma variável de ambiente, para apontar o mediator ao Wolverine. Nenhuma asserção mudou. Nenhum arquivo de src/ foi tocado.

Tudo abaixo foi compilado e executado na máquina do Roger, numa worktree própria em Gryd.IO/spike-wolverine, na branch spike/wolverine-sucessor-mediatr a partir de 879dd954. A pasta de trabalho principal continuou na feature/grydfiles-modulo-plataforma, sem alteração.

O trabalho foi feito em duas camadas, de propósito:

Os quatro que caem no porte ingênuo têm nome: SystemAdmin_InAGroupTenant_ShouldSeeTheGroup_NotThePlatform, GroupSummary_ShouldReportTheScopeAndLabelEveryCompany e as duas variantes de TheAnnouncedGroupReach_IsExactlyTheGroupCallOutcome. São exatamente as leituras de grupo — e nenhuma outra.

Correção ao roteiro, conferida em 879dd954: o repositório tem 12 implementações de IPipelineBehavior<,>, não 13. MissingDatabaseBehavior é um enum de política de risco em GrydAuth.Application/Common/Security/, não um behavior de pipeline. O nome enganou a tabela.

Um a um, com a evidência bruta. Onde a evidência é um erro de compilador ou uma saída de teste, ela está aqui literalmente — não a paráfrase dela.

1 · Os behaviors críticos cabem no pipeline passa

Passa a ordem; falha a letra "sem ordem implícita". Os três behaviors foram portados e rodam na ordem declarada. A ordem foi gravada passo a passo pelo próprio pipeline:

order (probe A · permissão + escopo de grupo):
  permission > tenantscope:resolve > tenantscope:apply > handler > tenantscope:finally

order (probe B · permissão + cross-tenant):
  permission > crosstenant > handler > crosstenant:finally

Duas coisas boas aparecem aqui e não estavam previstas. A primeira: o Wolverine não gera o middleware que não se aplica ao tipo da mensagem — a sonda A não tem crosstenant na cadeia, enquanto o MediatR chama o behavior e volta na primeira linha. É mais barato, e a ordem fica declarada no registro, não implícita na composição.

A segunda: o Before de um middleware pode devolver um valor que o Before de outro recebe por tipo. É isso que torna o contorno do AsyncLocal possível sem estado estático novo — o critério proíbe exatamente isso, e o contorno não precisou dele.

O que não passa na letra do critério é "nenhum precisa de ordem implícita para funcionar". O behavior de escopo de grupo precisa ser partido em duas metades, e a segunda tem de ser a última antes do handler. Isso é uma ordem implícita: nada no código diz, nenhum compilador acusa, e o teste que a violaria fica verde na maioria das suítes. Está detalhado em § O que aconteceu com a tenancy.

2 · A tenancy sobrevive passa

157 de 157, sem editar um teste. As suítes Tests.Authorization (121), Tests.Directory e Tests.GroupScope (36) rodaram com o GrydAuth inteiro despachado pelo Wolverine:

Aprovado!  – Com falha: 0, Aprovado: 157, Total: 157, Duração: 1 m 37 s

wolverine sends ........: 355
mediatr sends ..........: 0
permission gate ran ....: 19
cross-tenant filter off : 18
group scope resolved ...: 25
group scope applied ....: 25

O verde só vale porque os contadores mostram que os três behaviors críticos fizeram trabalho: 19 avaliações de permissão, 18 desligamentos do filtro entre tenants, 25 escopos de grupo resolvidos e aplicados. Uma execução anterior — antes de estender o roteamento a todas as requisições — também ficou 121/121 verde com o gate de permissão executando zero vezes. Aquele verde não dizia nada, e é por isso que os contadores existem.

3 · O AggregateRoot é raspável passa

Sem tocar a classe, e sem tocar as 74 chamadas. A API do Wolverine aceita a coleção que o IAggregateRoot já expõe:

opts.PublishDomainEventsFromEntityFrameworkCore<IAggregateRoot, DomainEvent>(a => a.DomainEvents);

IAggregateRoot.DomainEvents já é public IReadOnlyCollection<DomainEvent>. O critério permite "no máximo expor a coleção"; nem isso foi preciso. Um agregado de teste que herda o AggregateRoot real, com um AddDomainEvent na forma exata dos 74 pontos, teve o evento raspado, gravado no outbox e entregue ao handler contra um PostgreSQL real.

4 · O GrydJobs não é perdido passa

O Hangfire convive; ninguém precisa assumir nada. O GrydJobs tem sua própria camada de provider (HangfireJobScheduler, HangfireJobMonitor), e o Wolverine entra ao lado sem disputar dashboard, DLQ ou política de retry. O que o Wolverine cobra é colateral de pacote, e é obrigatório:

error NU1109: Downgrade de pacote detectado: Cronos de 0.11.0 para 0.8.4 definido centralmente.
  Spike.Wolverine -> WolverineFx 6.35.0 -> Cronos (>= 0.11.0)
  Spike.Wolverine -> Cronos (>= 0.8.4)

O Cronos é usado pelo GrydReports.Infrastructure e pelo GrydJobs.Infrastructure. Subi para 0.11.0 no Directory.Packages.props e medi a consequência: a solução inteira compila com 0 warnings e 827 testes de GrydJobs, GrydReports e Notifications ficam verdes. Passa — mas note que adotar o Wolverine obriga um bump transitivo num pacote de agendamento que não tem nada a ver com mensageria.

5 · O impacto no consumidor é declarável passa em forma

Cabe em uma página, e a página é a § Impacto no consumidor. Passa em forma; o conteúdo dela é que decide se é vendável, e há pelo menos um item — o despacho pós-commit — que muda semântica visível de quem já usa o framework.

6 · O Wolverine acompanha o Hybrid falha

A chave de resolução tem tamanho errado, e isso é verificável em duas camadas. Primeiro no compilador:

Wolverine  : FindAsync(String tenantId)
Gryd.IO    : ResolveAsync(Nullable`1 tenantId, String moduleName, CancellationToken cancellationToken)

Depois no banco. Montei três bancos PostgreSQL — shared, dedicated_auth e dedicated_files — e um catálogo na forma que o TenantConnectionStringResolver devolve no modo Hybrid: o tenant tenant-hybrid com GrydAuth num banco dedicado e GrydFiles em outro banco dedicado. Registrei os tenants no Wolverine por uma fonte fixada num módulo e publiquei uma mensagem durável para o tenant:

envelope tables · dedicated_auth=3  dedicated_files=0  shared=3

O banco do outro módulo do mesmo tenant ficou com zero tabelas do Wolverine. Não há inbox, não há outbox, e — o que importa — não há agente de durabilidade varrendo aquele banco. Um envelope gravado ali pelo DbContext do GrydFiles, na mesma transação do dado de negócio, nunca sairia.

composite key · dedicated_auth=3  dedicated_files=3

Some-se um detalhe menor mas real: PersistMessagesWithPostgresql exige um connection string "main" antes de qualquer tenant existir. O Gryd.IO não tem um banco global — tem ModuleDefaults por módulo e um DefaultConnectionString de fallback. Dá para apontar um; é mais um conceito importado do que uma peça que já existia.

Seis contornos. Nenhum é fatal isolado; juntos são o custo real da migração, e é isso que uma estimativa por contagem de arquivos não captura.

InvalidOperationException: Wolverine is running in TypeLoadMode.Dynamic, which compiles
handler/middleware code at runtime, but no IAssemblyGenerator (Roslyn) is registered.
Core WolverineFx no longer ships the runtime compiler. (GH-2876)

JasperFx.CodeGeneration.UnResolvableVariableException: JasperFx was unable to resolve a
variable of type GrydAuth.Application.Common.Interfaces.IRequirePermission as part of the
method ProbeRequestHandler118808494.HandleAsync(...)

CS0136: Um local ou um parâmetro denominado "disposable" não pode ser declarado neste
escopo porque esse nome é usado em um escopo delimitador de local

Wolverine.Configuration.InvalidServiceLocationException: Found service locations while
generating code for Message Handler for GrydAuth.Application.Features.MultiTenancy.Queries
.GetTenantsAdminQuery, but ServiceLocationPolicy.NotAllowed is in effect

O mecanismo, isolado do Wolverine

Antes de acusar o produto, o mecanismo foi medido sozinho, num teste que não menciona o Wolverine:

static async Task WriteItAsync()
{
    await Task.Yield();
    TenantContextAccessor.ScopeTenantIds = new[] { Guid.NewGuid() };
}

WriteItAsync().GetAwaiter().GetResult();
TenantContextAccessor.ScopeTenantIds   // →  NULL

É comportamento documentado do .NET: o AsyncMethodBuilder restaura o ExecutionContext do chamador quando o método async termina, então mutação de AsyncLocal feita lá dentro não sobe. No MediatR isso nunca apareceu porque o using (_applier.Apply(scope)) { return await next(); } está no mesmo método async que chama o handler — a escrita desce, não sobe.

O mesmo mecanismo, dentro do Wolverine

O TenantScopeBehavior precisa das duas coisas ao mesmo tempo: await resolver.ResolveAsync(...) e applier.Apply(scope). Portado como um único Before async, o handler vê:

order: permission > tenantscope > handler > tenantscope:finally
scope seen by handler ...: NULL          ← duas empresas resolvidas, nenhuma aplicada

Repare que a ordem está certa e o finally roda. O middleware executou, resolveu o grupo, auditou a leitura e devolveu um descartável. Só o efeito colateral que importa se perdeu.

O contorno, e a regra que ele cria

Partir o behavior em duas metades: um Before async que só resolve, devolvendo o escopo; e um Before síncrono que recebe esse escopo por tipo e faz a escrita ambiente.

order (contorno): permission > tenantscope:resolve > tenantscope:apply > handler > tenantscope:finally
scope seen (contorno) ..: 22222222-…-2222, 33333333-…-3333    ← as duas empresas

Uma pergunta de acompanhamento, respondida em vez de assumida: um passo async entre a aplicação e o handler destrói a escrita? Não. Um middleware async registrado depois do apply deixou o escopo intacto. A regra é estreita e precisa: quem escreve tem de ser síncrono; quem só passa pelo caminho não importa.

Onde isso mordeu de verdade — e o que quase passou batido

O CrossTenantDataFilterBehavior passou de primeira, porque a sua resolução é síncrona. O TenantScopeBehavior foi corrigido pelo contorno. E aí a suíte ainda ficou vermelha em dois testes, com uma mensagem que é quase uma acusação:

InvalidOperationException: No tenant scope is in effect and there is no current tenant to
fall back to. A scope-capable read reached this point without tenant context, which means
the request bypassed tenant resolution.        → HTTP 409

A causa é o mesmo mecanismo num terceiro lugar, que ninguém teria procurado. O GrydAuthTenantContextAdapter.TenantId sincroniza o TenantContextAccessor como efeito colateral do getter:

public Guid? TenantId
{
    get
    {
        var httpContext = _httpContextAccessor.HttpContext;
        if (httpContext?.Items.TryGetValue(GrydAuthConstants.TenantIdKey, out var tenantIdObj) == true)
        {
            if (tenantIdObj is Guid tenantGuid)
            {
                EnsureTenantContextAccessorSynced(tenantGuid);   // ← a escrita ambiente
                return tenantGuid;
            }
            …

Sob o MediatR, a primeira leitura acontece dentro da cadeia de behaviors, num fluxo async contínuo até o handler, e a escrita fica. Sob o Wolverine, a primeira leitura caiu dentro de um Before async — e o handler rodou sem tenant ambiente nenhum. O que devolveu o verde foi um middleware síncrono de três linhas cujo único trabalho é ler a propriedade antes de todo mundo.

E o query filter global?

Aqui está a razão de isto ser uma regra de segurança e não de estilo. O predicado que o EF Core compila para toda entidade com tenant obrigatório é:

e => !context.IsTenantFilterEnabled ||
     (context.ScopeTenantIds != null
        ? context.ScopeTenantIds.Contains(e.TenantId)
        : context.CurrentTenantId == null
            ? !context.RequireTenantOnRead      // ← sem tenant E sem escopo
            : e.TenantId == context.CurrentTenantId);

RequireTenantOnRead é um bool sem inicializador: vale false por padrão. Com o AsyncLocal vazio nas duas pontas, o ramo escolhido é !false — literalmente predicado sempre verdadeiro, nenhum filtro. Nos casos que este spike observou, o código falhou fechado (409 e 422) antes de chegar à consulta, porque o ICurrentTenantScope se recusa a operar sem tenant. Mas essa proteção é de uma camada acima; o predicado abaixo dela está pronto para devolver o banco inteiro se alguma leitura chegar lá com as duas pontas nulas.

O que muda para quem já constrói sobre o Gryd.IO — um módulo, um serviço, o Nexio. Uma página, que é o critério.

A linha que exige atenção. Hoje o GrydAuthDbContext.SaveChangesAsync roda um laço: salva, despacha os eventos de domínio, e se algum handler gerou novas mudanças, salva de novo — até 10 iterações, tudo dentro de uma transação. É por isso que um handler que incrementa TokenVersion hoje "simplesmente funciona".

O Wolverine entrega o evento depois do commit — medido em 767,8 ms na sonda deste spike. Isso é melhor (é justamente o que o roteiro do épico quer: nada é anunciado antes de o banco confirmar), e é incompatível com qualquer handler que hoje dependa de participar da mesma transação. São 74 pontos de AddDomainEvent a auditar, um a um, para separar "quero avisar" de "quero completar a escrita".

O 199 do roteiro não se reproduz em 879dd954. As medidas vizinhas, feitas com grep no commit conferido, são estas:

O que eu de fato toquei

Total, sem o Hybrid: 6 a 10 semanas de uma pessoa, com a faixa dominada pelas duas frentes semânticas — os behaviors e os eventos de domínio —, não pela contagem de arquivos. Com o Hybrid na conta, não há número: a questão deixa de ser prazo e vira decisão de produto.

A extrapolação é válida na direção "mecânico" e frágil na direção "semântico". Portei 6 behaviors em uma sessão, mas os 6 que sobraram incluem os três de observabilidade, que envolvem o handler em spans e cronômetros — exatamente a forma using que mais dói. O número acima assume que eles doem como o TenantScope doeu, e essa é a suposição mais frágil do quadro.

O gatilho, escrito de forma que dê para verificar sem discussão:

O que fazer enquanto isso, e que não é esperar. As features F3 a F6 do épico devem ser construídas como especificadas — a versão fina do outbox no Core. Duas razões, e a segunda é a que importa:

Toda afirmação sobre o Gryd.IO vem de git show 879dd954:<arquivo> no repositório, com o caminho citado no próprio texto. Toda afirmação sobre o Wolverine vem daqui:

Toda afirmação executada nesta versão vem de um artefato no repositório, na branch spike/wolverine-sucessor-mediatr, commit aef01e2f:

A superfície de API do Wolverine citada aqui foi lida por reflection sobre os assemblies 6.35.0 de fato restaurados, não só pela documentação — o despejo está em _spike/logs/20-api-surface.txt. Onde documentação e assembly discordaram, vale o assembly. A documentação continua sendo a fonte para intenção e contexto:

• Wolverine · Middleware — a forma gerada Before/try/After/finally/Finally, o retorno do Before reaproveitado nos métodos posteriores, HandlerContinuation.Stop, injeção de construtor em middleware não estático.
• Wolverine · EF Core integration — UseEntityFrameworkCoreTransactions(), AddDbContextWithWolverineIntegration<T>(), o outbox sobre a conexão e a transação do DbContext.
• Wolverine · Publishing Domain Events — PublishDomainEventsFromEntityFrameworkCore<T>(x => x.Events) e o exemplo com coleção mutável.
• Wolverine · Multi-Tenancy with EF Core — RegisterStaticTenants(), IDynamicTenantSource<string>, AddDbContextWithWolverineManagedMultiTenancy, conjoined tenancy e WolverineFx.RuntimeCompilation.
• Wolverine · PostgreSQL Integration — PersistMessagesWithPostgresql, UseMasterTableTenancy(), um connection string por tenant id e a exigência do banco "main".
• JasperFX · One Application, Many Brokers — AddTenant(...) nos dez transportes, carimbo e propagação do tenant id, TenantIdBehavior.
• JasperFx/wolverine · issue #2585 — DomainEventScraper e "Collection was modified" com DbContext compartilhado, em 5.32.0 com .NET 10 e EF Core 10; corrigido pelo #2594.
• JasperFx/wolverine · LICENSE — MIT.
• NuGet · WolverineFx — versão 6.35.0, publicada em 08/09/2026, alvos net9.0 e net10.0.

Os resultados desta página são o relato histórico do spike, preservados: 157 testes de tenancy/diretório/escopo, 355 despachos, 827 testes de jobs/reports e cinco de seis critérios atendidos. Base reportada 879dd954, trabalho em spike/wolverine-sucessor-mediatr; referência de resultado aef01e2f. Essa referência de resultado não estava disponível no checkout local para reprodução desta revisão.

Não reapresentar essas contagens como testes executados neste PR nem como garantia para versões atuais. O resultado pós-commit medido não cobre automaticamente duas transações/DbContexts na mesma requisição, savepoints, leases interrompidos ou restauração. O cenário Hybrid foi reprovado no relato.

Decisão vigente: manter MediatR e adiar Wolverine. Implementar o mecanismo de plataforma conforme Eventos e outbox, com tabela e migração no contexto produtor. Reavaliar adoção somente com gatilho documentado e reprodução das provas nas versões efetivamente consumidas.