The real fix to our EF Core + Outbox problem. Bump to 5.36.2

Directory.Build.props

@@ -11,7 +11,7 @@
         <NoWarn>1570;1571;1572;1573;1574;1587;1591;1701;1702;1711;1735;0618;VSTHRD200</NoWarn>
         <ImplicitUsings>true</ImplicitUsings>
         <Nullable>enable</Nullable>
-        <Version>5.36.1</Version>
+        <Version>5.36.2</Version>
         <RepositoryUrl>$(PackageProjectUrl)</RepositoryUrl>
         <PublishRepositoryUrl>true</PublishRepositoryUrl>
         <EmbedUntrackedSources>true</EmbedUntrackedSources>

src/Http/Wolverine.Http/HttpChain.Codegen.cs

@@ -174,6 +174,8 @@ internal IEnumerable<Frame> DetermineFrames(GenerationRules rules)
 
     private bool requiresFlush(Frame[] actionsOnOtherReturnValues)
     {
+        if (Middleware.Any(x => x is IFlushesMessages)) return false;
+        if (Postprocessors.Any(x => x is IFlushesMessages)) return false;
         if (Postprocessors.Any(x => x.MaySendMessages())) return true;
         if (actionsOnOtherReturnValues.Any(x => x.MaySendMessages())) return true;
 

src/Persistence/EfCoreTests/Optimistic_concurrency_with_ef_core.cs

@@ -20,7 +20,6 @@
 namespace EfCoreTests;
 
 [Collection("sqlserver")]
-[Trait("Category", "Flaky")]
 public class Optimistic_concurrency_with_ef_core
 {
     private readonly ITestOutputHelper _output;
@@ -56,15 +55,27 @@ public async Task detect_concurrency_exception_as_SagaConcurrencyException()
             using var scope = host.Services.CreateScope();
             var dbContext = scope.ServiceProvider.GetRequiredService<OptConcurrencyDbContext>();
 
+            // The saga's Id and the message's Id must match — Wolverine looks up the
+            // saga by the message's correlation Id (the `Id` field on
+            // UpdateConcurrencyTestSaga). Without a matching row the load throws
+            // UnknownSagaException before the handler can fake a concurrent update,
+            // which is what was making this test unconditionally fail (it was tagged
+            // [Flaky] but the failure was deterministic, not racy). With matching
+            // ids the saga loads, the handler's `OriginalValue = 999` trick simulates
+            // a stale read, SaveChangesAsync raises DbUpdateConcurrencyException, and
+            // EFCorePersistenceFrameProvider.WrapSagaConcurrencyException rethrows it
+            // as SagaConcurrencyException.
+            var sagaId = Guid.NewGuid();
             await dbContext.ConcurrencyTestSagas.AddAsync(new()
             {
-                Id = Guid.NewGuid(),
+                Id = sagaId,
                 Value = "initial value",
                 Version = 0,
             });
             await dbContext.SaveChangesAsync();
 
-            await Should.ThrowAsync<SagaConcurrencyException>(() => host.InvokeMessageAndWaitAsync(new UpdateConcurrencyTestSaga(Guid.NewGuid(), "updated value")));
+            await Should.ThrowAsync<SagaConcurrencyException>(() =>
+                host.InvokeMessageAndWaitAsync(new UpdateConcurrencyTestSaga(sagaId, "updated value")));
         }
         finally
         {

src/Persistence/Wolverine.EntityFrameworkCore/Codegen/EnrollDbContextInTransaction.cs

@@ -8,7 +8,7 @@
 
 namespace Wolverine.EntityFrameworkCore.Codegen;
 
-internal class EnrollDbContextInTransaction : AsyncFrame
+internal class EnrollDbContextInTransaction : AsyncFrame, IFlushesMessages
 {
     private readonly Type _dbContextType;
     private readonly IdempotencyStyle _idempotencyStyle;

src/Wolverine/Persistence/IFlushesMessages.cs

@@ -0,0 +1,7 @@
+namespace Wolverine.Persistence;
+
+/// <summary>
+/// Just a marker interface for the codegen that lets the codegen know
+/// that a Frame is taking care of flushing messages itself
+/// </summary>
+public interface IFlushesMessages;