Repository navigation
Bump WolverineFx from 6.39.1 to 6.44.0 - #108
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
--- updated-dependencies: - dependency-name: WolverineFx dependency-version: 6.44.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
|
Superseded by #109. |
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.39.1 to 6.44.0.
Release notes
Sourced from WolverineFx's releases.
6.44.0
This release came overwhelmingly from outside the core team. Six people outside JasperFx reported or fixed
the work in it, including three who sent the pull request themselves, and one report that reconstructed a
production cluster failure in enough detail to find two defects nobody had suspected.
Thank you
MessageIdentity.IdAndDestinationhad every destination's inbox row retired by the first handler to commit, losing the copies whose handlers had not run, with no dead letter and no log. Also reported GH-4704.propertiesToModify, so poison messages silently never reached$DeadLetterQueue. Bisected across 27 releases and identified why the existing tests were blind to it.TypeLoadMode.StaticignoredDisableConventionalDiscovery().The agent control queue stall (GH-4718)
@erdtsieck reported 5.4–6.7 MB agent commands being rejected on a sharded multi-tenant cluster — 512
databases, ~2,200 tenants, 37,000–58,000 agents — alongside agent assignment stalling for 30–60 minutes
after every node change, and explicitly marked the causal link between the two as a hypothesis rather than
a finding. It held, and the report's detail is what made both halves findable:
AgentStartBatchSize; stops took a destination's whole set in one envelope. A node shedding 7,592 agentsemitted a single ~6 MB command that the destination refuses to read at all. This is also why lowering
AgentStartBatchSizechanged nothing — that knob had never touched the stop path.expired-row cleanup share one transaction, so the failed read rolled back the very expiry that would have
cleared the offending row. The node then re-read it every poll and received no control message at all,
which is why the leader reported "confirmed 0 of N" for chunk after correctly-sized chunk.
addressed to.
Fixes
identity rather than the id alone, on EF Core (#4703) and on Marten, Polecat and Fisher (#4725). Both
also pick up the partition-aware statement, so a redelivered row can be retired under
EnableInboxPartitioning.[Entity],[All],[FirstOrDefault],[Queryable]or a query plan now enrolls the transaction. Mutating one and relying on the transactional middleware
previously saved nothing at all, on EF Core with no diagnostic. GH-4717 closes the same gap for every
other provider.
propertiesToModify.the promoting node happens to be able to build a local circuit.
DisableConventionalDiscovery().[Transactional]no longer reports a chain as transactional when no provider claimed itand no transaction was applied. HTTP endpoints affected by this stop advertising a 409 they cannot raise.
... (truncated)
6.43.0
A dependency release. The store pins had been queued behind two releases because every store's current version takes Weasel 9.36.0 as a floor, and 9.36 carried an Oracle regression. That is fixed upstream now, so all three move together.
JasperFx stays at 2.76.1.
This is why 6.43.0 is a minor rather than a patch. Nothing in Wolverine's own public API changed, but crossing six Weasel releases changes what a migration does:
MODIFY.DROP INDEXfor them. Fixed.Oracle: the node tables stop drifting
Two fixes in Wolverine itself, both needed to work with Weasel 9.38.0.
Column defaults are no longer hand-escaped. Wolverine wrote every Oracle timestamp default as
SYSTIMESTAMP AT TIME ZONE ''UTC'', with the quotes already doubled, because Weasel used to paste DDL verbatim into anEXECUTE IMMEDIATE '...'literal. Weasel 9.36 escapes literals itself, so both sides escaped and the executed default becameAT TIME ZONE ''UTC''— not a time zone region, and every table create failed withORA-01882.Identity columns are declared through
AutoIncrement()rather than in the type string.wolverine_nodes.node_numberand the node-record table'sidwere declared asNUMBER(10) GENERATED BY DEFAULT AS IDENTITY— with the clause written into the type. Oracle does not store it there: the catalog reports the type as plainNUMBER(10)and carries identity separately. The model could never equal what came back, so every migration emitted anALTER … MODIFYthat Oracle refuses withORA-01031.That type string was a workaround rather than an oversight —
AutoIncrement()emitted the identity clause after the null constraint, which isORA-03076, so it could not create a table at all. Fixed upstream in weasel#667 along with two related defects: identity was never read back fromALL_TAB_COLUMNS.IDENTITY_COLUMN, and a schema containing an identity column could not be dropped at all, because the teardown tried to drop the system-generated sequence behind it.Existing Oracle deployments should settle rather than migrate: the column is already
NUMBER(10)identity in the database, and 9.38.0 now reads that back, so the model matches it.Verification
Built pinned the way CI builds it (
-c Release -f net9.0), 0 errors and 0 warnings, then 17 database suites locally across PostgreSQL, SQL Server, MySQL, Oracle and SQLite — including Marten, Polecat, Fisher, claim check and leader election on four engines.OracleTestswent from 181 failing to 203 passing.6.42.0
A release driven almost entirely by what users reported. Five of the durability fixes below came from one reporter working a multi-tenant deployment hard enough to find them, and the pattern running through them is the same: a failure that belonged to one tenant was being paid for by every tenant, or was not being reported at all.
GH-4662.
PublishAsync/ScheduleAsyncmade outside a handler and outside any transaction, to a local queue made durable byUseDurableLocalQueues(), used to return without an error when the message store was unreachable. Four attempts inside ~400 ms, one line atInformation, and the message was gone — not even recovered after the database came back, because no inbox row was ever written.The cause was the shape of the retry rather than the retry itself.
RetryBlock.PostAsyncruns one attempt inline and posts the rest to its own worker, so the task the caller awaits completes the moment the first attempt fails. That is the right shape once an envelope is durable somewhere and recovery can find it; it is the wrong shape for the write that makes it durable, because there is no other copy.DurableWriteRetrykeeps the same 50/100/250 ms budget, awaits it inline, and lets the last exception reach the caller.Who is affected is narrower than it sounds. If you enlist a real outbox (EF Core, Marten,
DatabaseEnvelopeTransaction) nothing changes — that path never reached this code. Inside a handler nothing new escapes either; the publish is buffered and a failure is still caught, logged and recorded as a discard, just atErrorwith a real tracking event instead of a buriedInformationline. Only the un-transacted publish from outside a handler can now throw.One tenant's outage stops costing you every tenant
timestampdefault is now a true UTC instant (GH-4663). It depended on the session's time zone, soInboxStaleTimehanded back envelopes that were still running.Partitioning
A scheduled message no longer runs on a node that does not own the slot (GH-4673). Under global partitioning a scheduled envelope took the local shortcut regardless of slot ownership, so two nodes could process the same group id concurrently — the exact thing partitioning exists to prevent. A promoted scheduled envelope also no longer still reports its status as
Scheduled.HTTP
Stream large multipart uploads through a
MultipartReaderendpoint parameter, contributed by @erdtsieck (#4674) — no buffering the whole upload to handle it. F# code generation emits the new frame too, and the F# codegen coverage is now gated against a committed baseline so a new unsupported frame cannot slip in unnoticed.Diagnostics, metrics and operations
local://destination was being classified as System traffic, so a user's own local queue never reached the per-type/per-tenantDeadLettersmetric (GH-4665).BrokerResource.Checkno longer reports a thrown check as a missing resource (GH-4693), which was hiding the real cause behind "Missing known broker resources".ShardStartException.Reason.SqliteNodePersistencehonors the table prefix (GH-4668); node shutdown failed outright on a prefixed store.Dependencies
node_numbercolumn that is alreadyGENERATED BY DEFAULT AS IDENTITYis read back as drift, so every migration emits anALTER ... MODIFYthat Oracle refuses. It will ship once that is fixed upstream.Thank you
MultipartReaderstreaming upload support in #46746.41.0
28 commits since V6.40.0. Minor rather than patch because of the new EF Core and topology features below — and because one change is breaking.
AutoApplyTransactions()now fails the chain build when two persistence providers can own it (#4631). A handler taking both aDbContextand a Marten/Polecat/FisherIDocumentSessionmatched two providers, andAutoApplyTransactionsapplied neither — no transaction support, no warning, no log line, and whatever the un-owned store buffered was discarded when the scope closed.[Transactional]on the same handler took the first ordered provider instead, so the document session was never saved. Both outcomes were silent and the handler reported success.This stops an application that starts today. One that writes through two stores from a single handler has been losing one of those writes all along; it will now refuse to build until the handler says which store owns the transaction. Add
[Transactional(typeof(X))]or[Storage(typeof(X))], or[NonTransactional]to opt out. Two-provider atomicity remains unsupported — the designated store commits, the other does not. Saga chains are exempt.Entity Framework Core
Lightweightmessage handler now enlist in the sameSaveChangesAsync()as the business write, andPublishDomainEventsFromEntityFrameworkCore()— inert inLightweightbefore — runs on every path.EfCoreOpsset-based operations (#4629), which force the eager transaction they need rather than failing quietly.Update<T>orStore<T>rather thanIStorageAction<T>used to silently save nothing.Multi-tenancy
Envelope.TenantIdis normalised throughTenantIdStyle(#4640).MessageContext.TenantIdalways applied the style andEnvelope.TenantIdnever did, so underForceLowerCasea handler saw"RED"on the envelope beside"red"on the context. Polecat and Fisher read the envelope, so they wrote the raw casing — invisible on SQL Server's case-insensitive collation, and on Fisher's BINARY collation the row was unreachable.OutboxedSessionFactoryresolves theMainstore lazily (#4633).Transports and topology
ListenToKafkaTopicsgroup and stamping the topic asDestination— thanks @lahma.Durability and correctness
EnqueueDirectlyAsyncretires the inbox row it forwards (#4645). A delayed message sent from a handler to a database-backed queue that another node owns was silently destroyed: the forwarding node left anIncomingrow behind, and the owning node's anti-duplicate probe then deleted the queue row it had just written. Nothing logged, nothing dead-lettered. Reported with a full four-step reconstruction by @smoqmilus.EndpointCollection._listenersis no longer a plainDictionary(#4646). A failover handing one node several exclusive listener agents at once had up to ten threads writing it while every send read it; aDictionarycorrupted mid-resize is poisoned permanently, and the node never routed again until the pod was replaced. Also reported by @smoqmilus.Activity. Recurring occurrences (#4647), inline receivers (#4649) and the agent plumbing loops (#4650) were parenting every message under whateverActivity.Currenthappened to be live when the agent or listener started.AddMessageHandler.Also
Contributors
Thanks to @erdtsieck, @jakobt, @lahma, @skoging and @smoqmilus.
6.40.0
51 commits since V6.39.1. A minor release rather than a patch, because this wave carries new capability and not only fixes.
New capability
ExternalTableTransportCompliancesuite now holds Oracle, PostgreSQL, SQL Server, MySQL and Sqlite to the same bar.Behaviour changes
404 ProblemDetailsinstead of500(#4516).409with a one-line opt-in (#4512).MissingNamedConnectionStringsExceptionstays anInvalidOperationException(#4527), and every named connection string is now validated in one pass at startup.Exception message wave
#4511–#4532 — 18 PRs making the framework's exceptions name a remedy rather than only a symptom: saga failures, handler discovery, SNS/Rabbit MQ/Azure Service Bus/Redis/SignalR configuration problems, oversized messages, unreadable HTTP bodies, and the transports' previously message-less exceptions.
Fixes
DeleteAllHandledAsyncwork (#4509).ISendMyselfpublished from a projection side effect, on all three stores (#4556) — built on @erdtsieck's #4557.Discard()to the inbox table (#4565).Dependencies
Unchanged from 6.39.1 — Marten 9.35.0, Polecat 5.29.0, Fisher 1.10.0, Weasel 9.32.0, JasperFx 2.74.0. This release ships exactly what its CI has been green against; the pin bump follows separately.
Contributors
Thank you to everyone who contributed code to this release:
ISendMyselfprojection side effect fix, #4557Commits 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)