Bump WolverineFx and WolverineFx.RuntimeCompilation#166
Merged
Conversation
Bumps WolverineFx from 6.16.0 to 6.17.3 Bumps WolverineFx.RuntimeCompilation from 6.16.0 to 6.17.3 --- updated-dependencies: - dependency-name: WolverineFx dependency-version: 6.17.3 dependency-type: direct:production update-type: version-update:semver-minor - dependency-name: WolverineFx.RuntimeCompilation dependency-version: 6.17.3 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updated WolverineFx from 6.16.0 to 6.17.3.
Release notes
Sourced from WolverineFx's releases.
6.17.3
Bug-fix and scale release, following the 6.17.2 community sweep. Every item below came from a community report or a review finding — thank you all.
Closed issues
PeriodicTimer, so at high database counts the metrics polling itself became significant connection pressure. Agents now register their store with a node-wide sequential sweeper that walks the node's databases one at a time across theUpdateMetricsPeriodwindow — at most one metrics connection in flight per node, regardless of database count. The registration set is re-read every pass, so databases join and leave the sweep as agents start and stop without a restart.Disconnectedstate that #3187 fixed. Two follow-ups are tracked in #3391.TrackedSessionwould pick up and then sit waiting on messages the test never sent. The default ignore rule now covers all ofINotToBeRouted(agent commands and framework telemetry), with a deliberate carve-out forAcknowledgement/FailureAcknowledgement, which the session's own acknowledgement APIs depend on. If you are on an older version,IgnoreMessagesMatchingType(t => t.CanBeCastTo<INotToBeRouted>())is the workaround.Fixes from review
UpdateMetricsPeriod = TimeSpan.Zerowould hot-spin the sweep loop (the pre-#3384PeriodicTimerthrew); it is now rejected at configuration time, withDurabilityMetricsEnabled = falseas the way to turn polling off.Marten test-helper:
PauseThenCatchUpOnMartenDaemonActivity#3388 — cold first catch-up appeared to stall (PR #3394, reported by @uniquelau). Investigated in depth. The reported mechanism — that
coordinator.ResumeAsync()does not start never-started shards — does not hold: under Wolverine-managed distribution the coordinator isWolverineProjectionCoordinator, whoseResumeAsyncbuilds the daemon lazily and starts every shard, bypassing agent assignment entirely. The cold path works, and there are now four tests proving it (including with a second subscription-agent consumer sharing the agent family).The real defect was a timeout mismatch, and it explains the reported symptom exactly. The stage runs inside a child
TrackedSessionwhose token cancels atTrackedSession.Timeout— 5 seconds by default — while the catch-up ignored that token and waited on an internal 60-second budget. The session gave up first and left the catch-up envelope started-but-never-finished, which reads as a hang. This is a genuine 6.16 → 6.17 behavior change: the old activeForceAllfinished inside 5 seconds; resume-and-wait on a cold daemon or a busy machine does not. The catch-up now honors the session's token and raises an actionableTimeoutExceptionnaming the store and pointing atTrackActivity().Timeout(...).If you hit this on 6.17.0–6.17.2, raising the tracked-session timeout is the fix.
Docs
IMessageBus.InvokeAsync<T>and the chain that runs is the handler's. The header-identified gap is tracked as #3385, with a clear diagnostic planned.Timeout()bounds the whole session including its stages, so a slow stage likePauseThenCatchUpOnMartenDaemonActivity()is capped by the session's 5-second default, not by any budget internal to the stage.Full changelog: JasperFx/wolverine@V6.17.2...V6.17.3
6.17.2
Community-issue sweep release. Every fix below shipped same-day from issues filed by the community — thank you all.
Closed issues
WolverineApiDescriptionProvidernow enumerates theHttpGraph(complete whenMapWolverineEndpoints()returns) instead of the start-timeEndpointDataSource, so ASP.NET's version-keyed cache can never freeze an empty first read. If you monitor Wolverine hosts with CritterWatch and expose OpenAPI, upgrade to this release (see JasperFx/CritterWatch#689).[AsParameters]+ compound-handlerLoadAsyncbinding the same route variable generated uncompilable code (CS0136/CS0841, host failed at startup) (PR #3381). Binding frames are now emitted once per chain and re-homed so any second consumer reuses them; both the[FromRoute]and[AsParameters]-parameter variants are covered. The related OpenAPI gap (route params bound only byLoadAsyncmissing from the operation) is tracked as #3380.[AsParameters]query binder silently ignored unparseable values (PR #3379). New opt-inWolverineHttpOptions.RejectUnparseableQueryValues: a present-but-unparseable query value short-circuits with a 400 ProblemDetails naming the parameter, matching ASP.NET minimal APIs; missing values keep their initializer in both modes. The default flips to strict in Wolverine 7.0.IMessageContext, plus a fullITenantDetectionPolicies-style mirror (opts.TenantId.IsRequestHeaderValue(...),IsClaimTypeNamed(...),DetectWith<T>()) that sets the codegen tenant variable Marten/Polecat session frames consume — with a zero-config default when the client stampstenant-id. New docs page: gRPC multi-tenancy.DurabilityMetricsEnabled = falseand raisingUpdateMetricsPeriodas mitigations for metrics-polling connection load at high tenant-database counts (PR #3378). The per-node sweeper implementation is in progress on the issue.Dependency bumps
6.17.1
Wolverine 6.17.1 is a bug-fix release covering EF Core outbox enlistment gaps in Wolverine.Http, persistence provider resolution, HTTP route parameter binding, multi-tenancy message store roles, and a RavenDB startup race. It also upgrades the Marten dependency to 9.14.1.
EF Core & persistence
DbContextand cascade messages only through a tuple return are now enlisted in the EF Core outbox, so cascaded messages are no longer sent before the transaction commits when usingLightweightmode (#3358, #3362)IStorageAction<T>/ storage side effects) are likewise enlisted in the EF Core outbox inLightweightmode (#3353, #3357)DbContext-based handlers get the correct transactional middleware (#3359, #3361)MessageStoreRole.Ancillaryis now honored for tenanted message stores (static tenants and master-table tenancy) instead of silently reportingMain(#3351), with the registration behavior now covered by tests across PostgreSQL, SQL Server, SQLite, MySQL, and OracleHTTP
[FromRoute(Name = "...")]is now honored on plain endpoint method parameters (previously only inside[AsParameters]types), enabling route segments like{journey-id}that aren't valid C# identifiers (#3356 — thanks to @outofrange-consulting!)RavenDB
Dependencies
Documentation
IDocumentSessionorDbContext), not the HTTP verb (#3355, #3360)6.17.0
Why is this such a big release? Because @jeremydmiller went on a 3 night vacation and the community decided to throw in issues and pull requests left and right!
A big theme was filling in the remaining gaps of "Name Broker" and "Broker per Tenant" support in every external messaging transport where it made sense to add that rather than just being Rabbit MQ, Azure Service Bus, and hit and miss everywhere else. We also added HTTP QUERY support.
What's Changed
... (truncated)
Commits viewable in compare view.
Updated WolverineFx.RuntimeCompilation from 6.16.0 to 6.17.3.
Release notes
Sourced from WolverineFx.RuntimeCompilation's releases.
6.17.3
Bug-fix and scale release, following the 6.17.2 community sweep. Every item below came from a community report or a review finding — thank you all.
Closed issues
PeriodicTimer, so at high database counts the metrics polling itself became significant connection pressure. Agents now register their store with a node-wide sequential sweeper that walks the node's databases one at a time across theUpdateMetricsPeriodwindow — at most one metrics connection in flight per node, regardless of database count. The registration set is re-read every pass, so databases join and leave the sweep as agents start and stop without a restart.Disconnectedstate that #3187 fixed. Two follow-ups are tracked in #3391.TrackedSessionwould pick up and then sit waiting on messages the test never sent. The default ignore rule now covers all ofINotToBeRouted(agent commands and framework telemetry), with a deliberate carve-out forAcknowledgement/FailureAcknowledgement, which the session's own acknowledgement APIs depend on. If you are on an older version,IgnoreMessagesMatchingType(t => t.CanBeCastTo<INotToBeRouted>())is the workaround.Fixes from review
UpdateMetricsPeriod = TimeSpan.Zerowould hot-spin the sweep loop (the pre-#3384PeriodicTimerthrew); it is now rejected at configuration time, withDurabilityMetricsEnabled = falseas the way to turn polling off.Marten test-helper:
PauseThenCatchUpOnMartenDaemonActivity#3388 — cold first catch-up appeared to stall (PR #3394, reported by @uniquelau). Investigated in depth. The reported mechanism — that
coordinator.ResumeAsync()does not start never-started shards — does not hold: under Wolverine-managed distribution the coordinator isWolverineProjectionCoordinator, whoseResumeAsyncbuilds the daemon lazily and starts every shard, bypassing agent assignment entirely. The cold path works, and there are now four tests proving it (including with a second subscription-agent consumer sharing the agent family).The real defect was a timeout mismatch, and it explains the reported symptom exactly. The stage runs inside a child
TrackedSessionwhose token cancels atTrackedSession.Timeout— 5 seconds by default — while the catch-up ignored that token and waited on an internal 60-second budget. The session gave up first and left the catch-up envelope started-but-never-finished, which reads as a hang. This is a genuine 6.16 → 6.17 behavior change: the old activeForceAllfinished inside 5 seconds; resume-and-wait on a cold daemon or a busy machine does not. The catch-up now honors the session's token and raises an actionableTimeoutExceptionnaming the store and pointing atTrackActivity().Timeout(...).If you hit this on 6.17.0–6.17.2, raising the tracked-session timeout is the fix.
Docs
IMessageBus.InvokeAsync<T>and the chain that runs is the handler's. The header-identified gap is tracked as #3385, with a clear diagnostic planned.Timeout()bounds the whole session including its stages, so a slow stage likePauseThenCatchUpOnMartenDaemonActivity()is capped by the session's 5-second default, not by any budget internal to the stage.Full changelog: JasperFx/wolverine@V6.17.2...V6.17.3
6.17.2
Community-issue sweep release. Every fix below shipped same-day from issues filed by the community — thank you all.
Closed issues
WolverineApiDescriptionProvidernow enumerates theHttpGraph(complete whenMapWolverineEndpoints()returns) instead of the start-timeEndpointDataSource, so ASP.NET's version-keyed cache can never freeze an empty first read. If you monitor Wolverine hosts with CritterWatch and expose OpenAPI, upgrade to this release (see JasperFx/CritterWatch#689).[AsParameters]+ compound-handlerLoadAsyncbinding the same route variable generated uncompilable code (CS0136/CS0841, host failed at startup) (PR #3381). Binding frames are now emitted once per chain and re-homed so any second consumer reuses them; both the[FromRoute]and[AsParameters]-parameter variants are covered. The related OpenAPI gap (route params bound only byLoadAsyncmissing from the operation) is tracked as #3380.[AsParameters]query binder silently ignored unparseable values (PR #3379). New opt-inWolverineHttpOptions.RejectUnparseableQueryValues: a present-but-unparseable query value short-circuits with a 400 ProblemDetails naming the parameter, matching ASP.NET minimal APIs; missing values keep their initializer in both modes. The default flips to strict in Wolverine 7.0.IMessageContext, plus a fullITenantDetectionPolicies-style mirror (opts.TenantId.IsRequestHeaderValue(...),IsClaimTypeNamed(...),DetectWith<T>()) that sets the codegen tenant variable Marten/Polecat session frames consume — with a zero-config default when the client stampstenant-id. New docs page: gRPC multi-tenancy.DurabilityMetricsEnabled = falseand raisingUpdateMetricsPeriodas mitigations for metrics-polling connection load at high tenant-database counts (PR #3378). The per-node sweeper implementation is in progress on the issue.Dependency bumps
6.17.1
Wolverine 6.17.1 is a bug-fix release covering EF Core outbox enlistment gaps in Wolverine.Http, persistence provider resolution, HTTP route parameter binding, multi-tenancy message store roles, and a RavenDB startup race. It also upgrades the Marten dependency to 9.14.1.
EF Core & persistence
DbContextand cascade messages only through a tuple return are now enlisted in the EF Core outbox, so cascaded messages are no longer sent before the transaction commits when usingLightweightmode (#3358, #3362)IStorageAction<T>/ storage side effects) are likewise enlisted in the EF Core outbox inLightweightmode (#3353, #3357)DbContext-based handlers get the correct transactional middleware (#3359, #3361)MessageStoreRole.Ancillaryis now honored for tenanted message stores (static tenants and master-table tenancy) instead of silently reportingMain(#3351), with the registration behavior now covered by tests across PostgreSQL, SQL Server, SQLite, MySQL, and OracleHTTP
[FromRoute(Name = "...")]is now honored on plain endpoint method parameters (previously only inside[AsParameters]types), enabling route segments like{journey-id}that aren't valid C# identifiers (#3356 — thanks to @outofrange-consulting!)RavenDB
Dependencies
Documentation
IDocumentSessionorDbContext), not the HTTP verb (#3355, #3360)6.17.0
Why is this such a big release? Because @jeremydmiller went on a 3 night vacation and the community decided to throw in issues and pull requests left and right!
A big theme was filling in the remaining gaps of "Name Broker" and "Broker per Tenant" support in every external messaging transport where it made sense to add that rather than just being Rabbit MQ, Azure Service Bus, and hit and miss everywhere else. We also added HTTP QUERY support.
What's Changed
... (truncated)
Commits viewable in compare view.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)