Repository navigation
build(deps): bump reactor-core from 3.4.17 to 3.4.18 - #4
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
Bumps [reactor-core](https://github.com/reactor/reactor-core) from 3.4.17 to 3.4.18. - [Release notes](https://github.com/reactor/reactor-core/releases) - [Commits](reactor/reactor-core@v3.4.17...v3.4.18) --- updated-dependencies: - dependency-name: io.projectreactor:reactor-core dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
the
dependencies
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
Bot
deleted the
dependabot/maven/io.projectreactor-reactor-core-3.4.18
branch
May 20, 2022 14:18
This was referenced Jul 28, 2026
astubbs
added a commit
that referenced
this pull request
Jul 31, 2026
Resolve the finding that highcpu Mutation was silently PR-scoped (GITHUB_BASE_REF is set on self-hosted pull_request runs too), contradicting the full-sweep docs. Rather than pick one, run both experimentally: split the matrix Mutation entry into Mutation (PIT, scoped) and Mutation (PIT, full). The full one sets PIT_FULL_SWEEP=true, a new explicit override in ci-mutation-test.sh that ignores the PR base ref and mutates all of internal.*. Also add fetch-depth: 0 to the highcpu checkout (repo is tiny) so the scoped job reliably resolves the PR base ref. Docs updated to match. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4 tasks done
4 tasks done
6 tasks done
astubbs
added a commit
that referenced
this pull request
Aug 25, 2026
… wedged poller is fatal at a backstop The code review's two remaining P1s, both on the sync lane's liveness. The deadlock (review finding #3, found independently by two reviewers): the control thread waited for a commit response while holding the commitCommand monitor for the whole cycle, and the broker-poll thread's onPartitionsRevoked blocked acquiring that same monitor - so the only thread that can produce the response could never run. Pre-branch the waiter's local deadline broke the cycle fatally in ~10s; this branch had removed that deadline, leaving no exit at all. Two composed fixes: - The monitor becomes a ReentrantLock (commitCycleLock) guarding exactly what the monitor guarded - the cycle and the command flag together, so a commit command can still only be placed between attempts. The revocation path is the one caller that may only ever tryLock (#29's own rule): on contention it declines with a WARN and defers, offsets stay dirty and travel to the new assignee. - commitAndWait gains a last-resort backstop at 4x offsetCommitTimeout + 60s: a poll thread that is alive but has serviced nothing for that whole window is wedged outside the commit path, commit state is unverifiable, and that is fatal - explicitly NOT the seam's budget exhaustion, which produces typed responses. The affirmative wait remains primary; merely-slow pollers are still waited out. The escalation clock (finding #4): deferral streaks escalated to the handler once they outlived offsetCommitTimeout - default 10 SECONDS - so the DEFAULT shutDown() handler killed instances during ordinary slow-but-healthy rebalances that pre-seam survived on WARNs, and each shutdown seeded the next rebalance. This overrides the plan's settled offsetCommitTimeout quantum, recorded at the declaration: the escalation clock is now rebalance-scale (5 minutes, parity with Kafka's default max.poll.interval.ms, test seam per the longPollTimeout precedent). Deferrals still WARN every cycle, never count as success, and clear on a real commit or assignment change. Also resolves the SpotBugs EI_EXPOSE_REP2 thread on CommitResponse (finding #15) with a justification comment - the payload is effectively immutable and the type is a package-internal single-producer channel; no annotations dependency exists to suppress with. Three new regression tests pin the fixes (revocation-declines, wedged-poller backstop, streak-outliving-budget-but-not-bound never escalates), each written to fail with the fix reverted; the four existing escalation scenarios drive the new bound through its test seam. Full core unit suite 448/448, all gates green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jCtV2yqQvxDR6cLML8J8a
astubbs
added a commit
that referenced
this pull request
Sep 2, 2026
…rupt as a wake-up, and end recovery on the failures retrying cannot fix Recovery lifecycle findings #3, #4, #8, #13, #17, #22, #23 and #27 of the #410 review, each with a test that was red against the previous code (run as a mutant of this commit - the old behaviour reinstated line by line - and green after). What changed for a user of the PC-built transactional path: - A replacement producer that was built but failed initTransactions is now closed before the retry is scheduled. It was leaked: nothing held a reference to it, and each one kept a KafkaProducer network thread - about 120 per hour at the 30 s backoff cap while a coordinator was unreachable. Both catch branches close it (ProducerManagerRecoveryTest: aReplacementThatFailsToInitialiseIsClosedBeforeTheRetryIsScheduled, aReplacementThatFailsTerminallyIsClosedToo). - The recovery counter and its log line moved out of the build try. The counter is the user's MeterRegistry, which has thrown from inside PC before (docs/solutions/runtime-errors/a-throwing-meter-registry-kills-the- poll-thread-and-strands-close.md); a throw there turned a published, in-use replacement into a DEFERRED outcome that scheduled a second rebuild against it (aThrowingMeterRegistryDoesNotTurnACompleted ReplacementIntoADeferredOne). - An interrupt while recovery waits for the producer write lock no longer closes the instance. notifySomethingToDo interrupts the control thread whenever the write lock is not HELD, and it is not held while WAITING for it - which recovery does for as long as a worker holds the produce lock through its user function; the rebalance that fenced the producer ends with onPartitionsAssigned, which notifies. The InterruptedException escaped maybeRecoverProducer's RuntimeException catch and the supervisor closed PC with no failure cause. It is now caught, cleared and the pass returns; the condition stays recorded and the next pass retries, the same shape as the mailbox poll's own catch. maybeRecoverProducer no longer declares InterruptedException, so the compiler holds the line (ProducerRecoveryTest: aWakeUpInterruptWhileRecoveryWaitsForTheWriteLock DoesNotCloseTheInstance - one record only, so the commit path's separate, pre-existing exposure to the same interrupt does not take it first). - An Error from the user's ProducerFactory is terminal. The factory is user code and is now wrapped by UserFunctions.carefullyRun like every other user function; an Error in the cause chain (a serializer's static initialiser failing, say) is deterministic and joins AuthorizationException and UnsupportedVersionException as a terminal build failure, so the instance closes naming the type, and its parked workers are released by the close. Before, the Error escaped every catch on the recovery path: the supervisor's catch is Exception, so the instance stayed RUNNING with every worker parked on the produce lock for good. maybeRecoverProducer also catches Error from anywhere else in the pass, records it as the failure reason and transitions to CLOSING before rethrowing, for the same release (anErrorFromTheFactoryIsTerminalAndClosesTheInstanceNamingIt). - A factory contract violation is terminal, not deferred. Returning null, returning the producer it already returned, or building a producer that does not carry the transactional.id PC handed it now raise ProducerFactoryContractException, a dedicated type the terminal predicate recognises. Every one is deterministic - a caching factory caches on every rebuild, never only the first - so retrying was a WARN-per-attempt loop for the life of the instance (aFactoryContractViolationIsTerminalRather ThanRetriedForever). - Recovery is skipped once the instance is CLOSING or CLOSED. A close during an outage otherwise waited on a rebuild that blocks up to max.block.ms for a producer nobody would use; ProducerManager.close releases the parked workers on its own. DRAINING still recovers, because a drain needs a producer to finish the work in flight (noReplacementIsAttemptedOnceThe InstanceIsClosing, driven directly - the window is the control thread's). Smaller: the two raw producerWrapper call sites the field javadoc claimed did not exist (sendOffsetsToTransaction and beginTransaction) go through producer(), and the javadoc now says exactly which paths read the field raw (the constructor and initProducer, before any replacement can exist); restoreWorkDiscardedByAbortedTransaction's count is named at its call site per the house rule; the pollAndProduceMany guard names producerConfig first and the Producer instance as deprecated. The terminal failure names the root cause's type as well as the wrapper's - types only, never messages, which may carry configuration values (R7). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VrpH51xNDodaajE4P2nhFg
6 tasks done
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
1 participant
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.
Bumps reactor-core from 3.4.17 to 3.4.18.
Release notes
Sourced from reactor-core's releases.
Commits
9f4ae94[release] Prepare and release 3.4.18f92011dUpgrade download, gradle enterprise, spotless, byteBuddy (#3034)e33211cInclude classname of null-returningmapfunction in NPE msg (#2984)ced9a12Upgrade Checkout action, Mockito, Spotless, Artifactory (#3030)adaec72Fix a Many sink / EmitterProcessor subscriber disposal leak (#3029)1be0d59Backport: contextView() implem of [Flux|Mono|Synchronous]Sink (#3026)a49fd63[release] Next development version 3.4.18-SNAPSHOTYou can trigger a rebase of this PR 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 mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@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)