audit: phase 1 round 02 quality assumptions

[samtrion]

Phase 1 — Round 02 — Quality Discovery

Repo Snapshot

• The Round 01 report (audit/assumptions/round-01-quality.md) is not present on main nor on any visible audit branch. Round 02 was scoped against the topical exclusions in the task brief (outbox/transports/idempotency/timeprovider) and the angles explicitly requested for new exploration.
• Solution targets net8.0;net9.0;net10.0 (Directory.Build.props). The source generator project (NetEvolve.Pulse.SourceGeneration) targets netstandard2.0, is shipped as a Roslyn analyzer pack (analyzers/dotnet/cs), and emits a single PulseRegistrations.Handlers.g.cs file.
• New surfaces inspected vs. Round 01: source generator pipeline, three event dispatchers, Polly v8 integration, FluentValidation interceptor, HttpCorrelation interceptors, ASP.NET Core MapCommand/MapQuery/MapStreamQuery, activity/metrics tagging, EF Core + SQLite + Mongo + Cosmos outbox repositories, query caching interceptor, multi-targeting #if branches, Testcontainers fixtures.
• Recent commits unrelated to the audit (Renovate / EF major updates / test deps).

Assumptions

Q13: DistributedCacheQueryInterceptor<TQuery, TResponse> registered as open-generic IRequestInterceptor<,> will fail DI resolution for non-query requests (commands and stream queries) because of its generic constraint where TQuery : IQuery<TResponse>.
Evidence: src/NetEvolve.Pulse/QueryCachingExtensions.cs:43-45 registers ServiceDescriptor.Scoped(typeof(IRequestInterceptor<,>), typeof(DistributedCacheQueryInterceptor<,>)); constraint in src/NetEvolve.Pulse/Interceptors/DistributedCacheQueryInterceptor.cs:40 requires TQuery : IQuery<TResponse>.
Why it matters: With AddQueryCaching() enabled, dispatching any command via SendAsync<TCommand,TResponse> (e.g. TCommand : ICommand<TResponse>) calls serviceProvider.GetServices<IRequestInterceptor<TCommand,TResponse>>() in PulseMediator.ExecuteAsync (PulseMediator.cs:232). .NET DI will attempt to close the open generic; if the constraint mismatch is detected eagerly, it throws ArgumentException and the command never runs. If detected only on instance creation, the failure mode is the same. Distinct from any Round-01 idempotency-flow note because it concerns DI closure semantics of constrained open generics on the request pipeline.
Test idea: Register AddQueryCaching() plus a single command handler with no validators; dispatch the command via IMediator.SendAsync<TCommand,TResponse> and assert it succeeds without throwing ArgumentException from DefaultServiceProviderFactory.

Q14: PrioritizedEventDispatcher swallows OperationCanceledException and rewraps it in AggregateException, while ParallelEventDispatcher and RateLimitedEventDispatcher use a when (!token.IsCancellationRequested) filter that lets cooperative cancellation surface as a true OperationCanceledException.
Evidence: src/NetEvolve.Pulse/Dispatchers/PrioritizedEventDispatcher.cs:100 catches Exception ex with no when guard; compare src/NetEvolve.Pulse/Dispatchers/ParallelEventDispatcher.cs:69 and src/NetEvolve.Pulse/Dispatchers/RateLimitedEventDispatcher.cs:114 which use when (!token.IsCancellationRequested).
Why it matters: Callers cannot rely on try { ... } catch (OperationCanceledException) to detect cancellation when the prioritized dispatcher is active; they receive an AggregateException containing the cancellation. Polly retry policies that classify OperationCanceledException as non-retryable will retry it under this dispatcher.
Test idea: Register two prioritized event handlers that throw OperationCanceledException(token) after cancellation. Assert that PublishAsync throws OperationCanceledException (matching the other dispatchers' contract) and not AggregateException.

Q15: ActivityAndMetricsRequestInterceptor writes ex.Message and ex.StackTrace as ActivitySource tags rather than calling Activity.AddException/RecordException, producing high-cardinality tag values and missing OpenTelemetry-standard exception events.
Evidence: src/NetEvolve.Pulse/Interceptors/ActivityAndMetricsRequestInterceptor.cs:130-135 sets ExceptionMessage, ExceptionStackTrace, ExceptionType, ExceptionTimestamp as tags via SetTag; no call to activity.AddException(...).
Why it matters: OpenTelemetry-aware exporters (OTLP, Azure Monitor, Honeycomb) look for the canonical exception.* event with exception.type/exception.message/exception.stacktrace on an exception event. Storing full stack traces as activity tags inflates trace storage and bypasses sampler/exporter exception-aware handling. Identical issue likely exists in ActivityAndMetricsEventInterceptor and ActivityAndMetricsStreamQueryInterceptor.
Test idea: Throw a known exception from a command handler with the interceptor enabled; collect via an ActivityListener, assert that the activity contains an exception event (not just custom tags) and that ex.StackTrace is not written to a tag.

Q16: ASP.NET Core endpoint helpers do not translate ValidationException (FluentValidation) or IdempotencyConflictException into RFC 7807 ProblemDetails responses; they bubble up to the global exception handler and produce HTTP 500 by default.
Evidence: src/NetEvolve.Pulse.AspNetCore/EndpointRouteBuilderExtensions.cs:60-65, 105-112, 142-149 directly await mediator.SendAsync/QueryAsync and wrap the result in TypedResults.Ok/NoContent — no exception filter, no IExceptionHandler, no per-exception status code mapping. IdempotencyConflictException (thrown by IdempotencyCommandInterceptor.HandleAsync at src/NetEvolve.Pulse/Interceptors/IdempotencyCommandInterceptor.cs:72) and ValidationException (FluentValidationRequestInterceptor.cs:75) have natural HTTP mappings (400/409) that are not produced.
Why it matters: Users expect Minimal API helpers to honor AddProblemDetails() for the common validation/conflict cases. Today the responses are inconsistent with Microsoft.AspNetCore.Mvc.ProblemDetails conventions and discoverability suffers.
Test idea: Hit a MapCommand-bound endpoint with an invalid command and an idempotency conflict respectively; assert the status code is 400/409 with application/problem+json content type when AddProblemDetails() is configured.

Q17: FluentValidationRequestInterceptor resolves validators via _serviceProvider.GetServices<IValidator<TRequest>>() and runs them sequentially on every request — there is no async-validator-throws guard (a non-ValidationException thrown by a validator escapes as the original exception, never logged) and no validator caching.
Evidence: src/NetEvolve.Pulse.FluentValidation/Interceptors/FluentValidationRequestInterceptor.cs:58-78. The await validator.ValidateAsync(request, cancellationToken) inside the loop is not wrapped; any non-validation exception (e.g. NRE in a custom validator) propagates as-is and bypasses the ValidationException branch.
Why it matters: A buggy validator that throws e.g. InvalidOperationException will look identical to a handler failure, defeating the centralization argument and confusing observability. Sequential validators also magnify async dispatch overhead when many validators target the same type. Distinct from any Round-01 ordering claim because it focuses on exception classification, not pipeline position.
Test idea: Register two IValidator<MyCommand>, one of which throws InvalidOperationException from ValidateAsync. Assert the interceptor surfaces InvalidOperationException (current behavior) — the test pins the contract; if the intended contract is to wrap, the test would fail.

Q18: HttpCorrelationRequestInterceptor mutates the incoming request DTO (request.CorrelationId = correlationId) directly, assuming CorrelationId is a writable property. If a consumer models a request as a record with init-only / read-only CorrelationId, the assignment fails at compile time only when the request type is exposed through the interface — the interceptor relies on the interface contract allowing setter access.
Evidence: src/NetEvolve.Pulse.HttpCorrelation/Interceptors/HttpCorrelationRequestInterceptor.cs:71 performs request.CorrelationId = correlationId; after a null check. The mutation happens before the handler executes and persists for the lifetime of the call (no cleanup).
Why it matters: For immutable command types (records with init setters surfaced via interface mutation), mutability of CorrelationId is forced by the framework. Also, mutating a caller-owned object is surprising; if the caller reuses the same DTO across multiple SendAsync calls (uncommon but legal), the correlation ID from one call leaks into the next.
Test idea: Build a record command whose CorrelationId setter has side effects; dispatch twice through the same scope with IHttpCorrelationAccessor returning two different IDs; assert the second dispatch overwrites the first rather than leaving the original. Also verify the mutation is visible to the caller after SendAsync returns.

Q19: The Roslyn incremental generator captures Microsoft.CodeAnalysis.Location into the HandlerInfo struct and the ExplicitTypeError record; HandlerInfo.Equals/GetHashCode deliberately excludes Location from equality, but pipelines further downstream (e.g. ImmutableArray<HandlerInfo> Combine/Collect comparers default to structural equality) may still treat two compilations as different and re-run Execute because Location instances are not stable across compilations.
Evidence: src/NetEvolve.Pulse.SourceGeneration/Models/HandlerInfo.cs:35-54 excludes Location from Equals. However the implicit ImmutableArray<HandlerInfo> equality used by Roslyn's Combine/Select operators uses IEqualityComparer<T>.Default only when T overrides Equals. The struct does override Equals, but ExplicitTypeError (src/NetEvolve.Pulse.SourceGeneration/Models/ExplicitTypeError.cs) needs verification — a record synthesized equality would include Location.
Why it matters: An incremental generator that re-runs Execute on every keystroke negates the perf benefits and may cause analyzer service starvation in large solutions. Round-01 did not cover incremental-pipeline equality.
Test idea: Write a generator-cache test using CSharpGeneratorDriver.GetRunResult().Results[0].TrackedSteps; assert that for a non-affecting edit (whitespace) the HandlerInfo and ExplicitTypeError pipeline steps are Cached rather than Modified.

Q20: Generated DI code in PulseHandlerGenerator.GenerateSource assumes the project's RootNamespace is a valid C# namespace identifier; non-identifier characters (e.g. dashes from an MSBuild-default RootNamespace derived from a folder name like My-App) produce uncompilable output.
Evidence: src/NetEvolve.Pulse.SourceGeneration/Generators/PulseHandlerGenerator.cs:628 var targetNamespace = string.IsNullOrWhiteSpace(rootNamespace) ? "NetEvolve.Pulse.Generated" : rootNamespace; then emits namespace {targetNamespace}; directly with no sanitization. The method name fallback Add{assemblyName!.Replace(".", string.Empty)}PulseHandlers (line 739) likewise replaces only dots — dashes and digits-prefixed assembly names are not handled.
Why it matters: Projects with non-identifier folder names (very common for dotnet new-generated tooling apps) will see the generator produce CS1031/CS1518 build errors with no diagnostic from PULSE001-006. The method-name path also breaks when assembly names start with a digit.
Test idea: Run the generator against a compilation whose RootNamespace is "My-Project" and assembly name is "1stPartyLib"; assert the emitted file either compiles cleanly (sanitized) or that a new PULSE diagnostic is emitted explaining the bad identifier.

Q21: SQLite outbox Type.GetType(stored event-type-name) is called without an assemblyResolver, so deserialization silently returns null and the repository throws a generic InvalidOperationException when the producing assembly is not currently loaded in the consumer process. There is no PluginLoadContext or fallback to scanning AppDomain.CurrentDomain.GetAssemblies().
Evidence: src/NetEvolve.Pulse.SQLite/Outbox/SQLiteOutboxRepository.cs:603-607 — Type.GetType(reader.GetString(ordEventType)) ?? throw new InvalidOperationException(...).
Why it matters: In a typical solution, the outbox table is read by a worker process that may not reference the producing API's events assembly. The current behavior is to crash the entire batch (not just skip the unresolvable message), preventing further outbox progress until manual intervention. Round-01's outbox concerns reportedly focused on transports/dispatch; this is a deserialization/type-resolution concern.
Test idea: Insert an outbox row whose EventType references an AssemblyQualifiedName for an assembly not loaded by the test host. Call GetPendingAsync and assert either: (a) the message is skipped with a logged warning, or (b) the entire batch fails — pinning current behavior.

Q22: Cosmos DB outbox uses id as the partition key path (/id, CosmosDbOutboxOptions.DefaultPartitionKeyPath); every outbox query (GetPendingAsync, GetFailedForRetryAsync, GetPendingCountAsync, DeleteCompletedAsync) is therefore a cross-partition fan-out query whose RU cost grows linearly with partition count.
Evidence: src/NetEvolve.Pulse.CosmosDb/Outbox/CosmosDbOutboxOptions.cs:16 sets DefaultPartitionKeyPath = "/id". Queries at src/NetEvolve.Pulse.CosmosDb/Outbox/CosmosDbOutboxRepository.cs:83-88, 109-114, 233, 251-253 do not set PartitionKey on QueryRequestOptions, so all reads are cross-partition. Furthermore ClaimMessagesAsync (line 331+) issues a per-message ReadItemAsync then PatchItemAsync, doubling RU cost.
Why it matters: At scale (>1000 messages/sec) the cross-partition query cost dominates; users will see RU throttling (HTTP 429) and unbounded latency. Picking /status or /createdAt (truncated) as the partition key — or using a logical synthetic key — would localize hot paths. Round-01 did not cover Cosmos partition-key strategy.
Test idea: Run a load test inserting 10k outbox messages, run a single batch poll, and capture RequestCharge from response headers; compare against the same load with a synthetic partition key (e.g. /statusBucket).

Q23: MongoDB outbox claim path executes up to batchSize sequential FindOneAndUpdateAsync calls per pickup, each of which is a round-trip; there is no aggregation pipeline $set+$match, no BulkWrite, and no transaction.
Evidence: src/NetEvolve.Pulse.MongoDB/Outbox/MongoDbOutboxRepository.cs:104-119 loops batchSize times calling FindOneAndUpdateAsync. With a default batch of 100 this is 100 sequential network round-trips.
Why it matters: Throughput is bounded by network latency × batchSize rather than by Mongo throughput. Worker pollers cannot scale horizontally because each instance independently performs serialized round-trips. The atomic claim is preserved but at significant cost.
Test idea: Run a poll against a Mongo container with 10ms ping latency; measure wall-clock time of GetPendingAsync(batchSize: 100); assert that it is dominated by 100 * latency (current behavior) — useful as a baseline for any future bulk-claim implementation.

Q24: EntityFrameworkOutboxRepository.AddAsync immediately calls SaveChangesAsync after AddAsync(message) (line 65-66), bypassing any unit-of-work transaction owned by the application's own DbContext for the same scope.
Evidence: src/NetEvolve.Pulse.EntityFramework/Outbox/EntityFrameworkOutboxRepository.cs:61-67 — await _context.OutboxMessages.AddAsync(...) followed by await _context.SaveChangesAsync(...) with no transaction check. Compare to the SQLite implementation at src/NetEvolve.Pulse.SQLite/Outbox/SQLiteOutboxRepository.cs:217-249 which honors an ambient IOutboxTransactionScope.
Why it matters: The EF Core outbox pattern fundamentally requires that the message persist in the same transaction as the domain entity that produced it. Forcing SaveChangesAsync inside AddAsync defeats that guarantee whenever the caller has not yet committed their own changes — the message ships even if the business SaveChanges later rolls back. This contradicts the "outbox pattern" promise and is qualitatively different from any retry/dispatch concern.
Test idea: Open an EF transaction, call EventOutbox.AddAsync for an event, then throw before committing. Assert the outbox row is rolled back (currently: it is committed).

Q25: PulseMediator.PublishAsync creates a fresh DI scope per call (_serviceProvider.CreateAsyncScope() at line 86) but QueryAsync/SendAsync resolve their handler and interceptors directly from the root IServiceProvider injected into the mediator — meaning command/query handlers receive scoped services from the consumer's scope, while event handlers receive a brand-new scope.
Evidence: src/NetEvolve.Pulse/Internals/PulseMediator.cs:86 for events vs lines 118 and 159 (_serviceProvider.GetRequiredService<...>) for queries/commands. The interceptor pipeline for queries/commands at line 232 uses the same root provider.
Why it matters: When PulseMediator itself is registered as a singleton (or root-scoped) instead of scoped, query/command handlers will resolve with the root IServiceProvider — a captive-dependency hazard. The asymmetry between event-scope creation and request-scope reuse is also surprising. Round-01 reportedly focused on dispatch concerns; this is a DI lifetime/scope contract question.
Test idea: Register PulseMediator as a singleton (intentional misconfiguration), then call SendAsync for a command whose handler depends on a scoped DbContext. Assert whether the resolved DbContext is shared across requests (captive) or per-scope.

Q26: Source-generator-emitted code includes namespace NetEvolve.Pulse.Generated; as a fallback (when RootNamespace is null), guaranteeing namespace collisions when multiple Pulse-aware assemblies coexist that both lack RootNamespace — both emit PulseRegistrationExtensions in the same namespace and the resulting public static partial class PulseRegistrationExtensions declarations clash across assemblies.
Evidence: src/NetEvolve.Pulse.SourceGeneration/Generators/PulseHandlerGenerator.cs:628 fallback namespace; line 650 emits public static partial class PulseRegistrationExtensions; method name derives from assembly name (line 739) but is not part of class identity — two assemblies that both emit this class in the same namespace would collide at the partial-class-merging step only when both are referenced into a third project that consumes both.
Why it matters: partial classes can only merge inside a single compilation, so two assemblies each defining PulseRegistrationExtensions in NetEvolve.Pulse.Generated will produce a CS0101 (duplicate definition) at consumption. The differing method names (AddXxxPulseHandlers) are not enough — the class name itself collides.
Test idea: Build two libraries that both depend on NetEvolve.Pulse source generator, neither with RootNamespace set, both with a single [PulseHandler] type. Reference both into a console app. Assert the compile succeeds (it currently should fail with CS0101 unless the generator namespaces them per assembly).

Q27: Polly interceptors throw InvalidOperationException from their constructor when no pipeline is registered for a given message type or globally, breaking DI graph construction at the first SendAsync rather than degrading gracefully.
Evidence: src/NetEvolve.Pulse.Polly/Interceptors/PollyRequestInterceptor.cs:89-94 (_pipeline = ... ?? throw new InvalidOperationException(...)) and src/NetEvolve.Pulse.Polly/Interceptors/PollyEventInterceptor.cs:88-93. Contrast PollyStreamQueryInterceptor.cs:62-65 which gracefully sets _pipeline = null and passes through.
Why it matters: A user who registers AddPollyRequestPolicies<CommandA, ...>() but dispatches CommandB will see CommandB blow up at construction with no pipeline. The behavior is inconsistent with the stream-query variant (which is the safer design). Distinct from generic policy-config concerns: this is specifically about constructor-throw vs. pass-through asymmetry across the three Polly interceptors.
Test idea: Register AddPollyRequestPolicies<CommandA, void>(...) only; dispatch CommandB (no policy registered). Assert the call either succeeds (stream-query parity) or fails with a clear "no policy for CommandB" message — current behavior produces InvalidOperationException from constructor reading ResolveService<ResiliencePipeline<TResponse>>() and the message references TResponse, not the command.

Q28: Activity tag name query.type for stream queries is not prefixed with pulse. like every other tag, breaking observability dashboards that filter by pulse.*.
Evidence: src/NetEvolve.Pulse/Internals/Defaults.cs:129 — internal const string StreamQueryType = "query.type"; while every other tag follows pulse.<area>.<field> (lines 71-134).
Why it matters: Operators building dashboards over Pulse instrumentation typically wildcard on pulse.*. The inconsistent prefix causes stream-query telemetry to silently drop out of those panels. Trivial to falsify and pin.
Test idea: Snapshot-test the full tag list emitted by all three activity interceptors (request, event, stream query); assert every tag key starts with pulse..

Q29: MapStreamQuery swallows OperationCanceledException from the underlying enumerator inside the Func<Stream, Task> delegate ("Client disconnected cleanly; do not re-throw."), which prevents Polly retry policies, ASP.NET Core diagnostics middleware, and Application Insights RequestTelemetry from observing client-cancellation events at all.
Evidence: src/NetEvolve.Pulse.AspNetCore/EndpointRouteBuilderExtensions.cs:222-235 (SSE) and :244-257 (NDJSON) catch OperationCanceledException and silently return.
Why it matters: Distributed tracing loses the cancel reason; rate-limiter middlewares cannot count cancelled requests; IExceptionHandler is never invoked for partial streams. Distinct from any prior cancellation concern because it lives in the HTTP-layer wrapper, not the dispatcher.
Test idea: Open a stream-query endpoint with Accept: text/event-stream, cancel the client mid-stream, and assert the server-side Activity.Current.GetTagItem("otel.status_code") is ERROR or Cancelled rather than implicit OK.

Q30: The #if NET10_0_OR_GREATER branch at EndpointRouteBuilderExtensions.cs:203 returns TypedResults.ServerSentEvents(items) but the fallback path (for net8.0 and net9.0) hand-rolls SSE framing with hard-coded "data: " prefix and "\n\n" separator, omitting the event:, id:, and retry: fields that real SSE clients negotiate over. The two code paths therefore produce semantically different SSE output across target frameworks of the same library binary.
Evidence: src/NetEvolve.Pulse.AspNetCore/EndpointRouteBuilderExtensions.cs:203-235. On net10.0, ASP.NET Core's TypedResults.ServerSentEvents may include retry/id/event fields and a different keep-alive behavior; on net8/9 it does not.
Why it matters: A user upgrading from net9 to net10 will observe a behavioral break in SSE responses without any code change. Round-01 did not enumerate multi-targeting branches.
Test idea: Compile the same endpoint under net9.0 and net10.0; issue the same request; diff the byte stream. Pin the differences (or fail if equal — current likely behavior is a real diff).

Q31: OutboxOptions.EnableWalMode triggers PRAGMA journal_mode=WAL on every opened connection (SQLiteOutboxRepository.CreateConnectionAsync line 484-491), not once at startup. Repeated WAL-mode pragmas on each connection are no-ops once set, but the extra round-trip per repository operation costs ~1ms per call against a remote SQLite (e.g. over a network filesystem) and is purely waste.
Evidence: src/NetEvolve.Pulse.SQLite/Outbox/SQLiteOutboxRepository.cs:479-494 — connection created and pragma issued in the same path used by every AddAsync, GetPendingAsync, MarkAsCompletedAsync, etc.
Why it matters: At sustained polling rates (every 100ms), the cumulative pragma overhead dominates other costs. WAL is also a database-level setting persisted across connections, so the repeated set is functionally redundant.
Test idea: Benchmark MarkAsCompletedAsync with EnableWalMode = true vs false against a 100ms-latency SQLite (over SMB share). Assert the per-call overhead is >10% lower when WAL is set once externally.

Q32: Testcontainers fixtures (PostgreSqlContainerFixture, CosmosDbContainerFixture, etc.) do not enable .WithReuse(true) and do not pin via labels, so every test class that depends on the fixture starts and tears down a fresh container, regressing local dev-loop wall-clock time and producing flaky container-name collisions under parallel TUnit execution.
Evidence: tests/NetEvolve.Pulse.Tests.Integration/Internals/Services/PostgreSqlContainerFixture.cs:9-14 — no WithReuse, no WithLabel. Same omission in CosmosDbContainerFixture.cs:9-13, RedisContainerFixture.cs, MongoDbContainerFixture.cs, MySqlContainerFixture.cs, SqlServerContainerFixture.cs.
Why it matters: Slow local feedback loop; CI is unaffected but developer experience suffers. Reuse via .WithReuse(true) (plus ~/.testcontainers.properties tc.host = testcontainers.reuse.enable=true) is the canonical Testcontainers performance lever.
Test idea: Time a full integration-test run for Pulse.Tests.Integration twice locally; the second run should not pay container-startup cost. Currently it does.

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)

• state:ready for merge

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 10360f4c-690c-430c-8d30-1d76bd6a4ae3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.85%. Comparing base (f46e83c) to head (43c8ba5).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #516      +/-   ##
==========================================
+ Coverage   92.80%   92.85%   +0.04%     
==========================================
  Files         164      164              
  Lines        6491     6491              
  Branches      561      561              
==========================================
+ Hits         6024     6027       +3     
+ Misses        307      305       -2     
+ Partials      160      159       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.