Bump WolverineFx from 6.17.1 to 6.17.3#532
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
--- updated-dependencies: - dependency-name: WolverineFx dependency-version: 6.17.3 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
|
Superseded by #535. |
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.17.1 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
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)