Repository navigation
build(deps): bump vertx.version from 4.2.7 to 4.3.1 - #12
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 `vertx.version` from 4.2.7 to 4.3.1. Updates `vertx-web-client` from 4.2.7 to 4.3.1 Updates `vertx-junit5` from 4.2.7 to 4.3.1 --- updated-dependencies: - dependency-name: io.vertx:vertx-web-client dependency-type: direct:production update-type: version-update:semver-minor - dependency-name: io.vertx:vertx-junit5 dependency-type: direct:development update-type: version-update:semver-minor ... 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. You can also ignore all major, minor, or patch releases for a dependency by adding an If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
astubbs
added a commit
that referenced
this pull request
Aug 6, 2026
…tates it Reverting these in the previous commit was a mistake, and the reasoning was the flaw: "the gate needn't demand it" is not "it shouldn't be there". The gate can see a link's target, so it correctly stops asking once one is present. A human cannot. Someone reading `issue #12` in this fork's README has no way to know it means confluentinc without hovering, and the fork has its own #12 - which is precisely the ambiguity the convention exists to kill. README.adoc is the published artefact and its readers are on the fork, so it is the worst place to rely on a hover. The phrasing is better than the version this PR originally shipped, too. The old gate ate the "[confluentinc" token off an asciidoc macro and then reported a bare "PR #291", which forced the clunky attached form everywhere. With the macro now stripped whole, any wording passes - so prose takes the house spaced form (`[confluentinc issue #12]`, `[confluentinc PR #291 ...]`) and quoted upstream titles keep the quotation intact with the number appended (`[Enhanced retry epic confluentinc#65]`). So the gate fix keeps its whole justification - it stops false positives tree-wide and stops the gate dictating prose - while the text gets clearer rather than merely compliant. AGENTS.md gains the rule, because the next reader would otherwise strip these out on exactly the reasoning above: a hyperlink satisfies the gate, not the reader. Written down as style rather than enforcement, since the gate will not flag it either way.
astubbs
added a commit
that referenced
this pull request
Aug 7, 2026
The reference gate requires any #NNN below the threshold to name its repo, because the fork's numbering sits entirely inside upstream's range and a bare number is a coin flip. It checks added lines only, so it never fired on text nobody was editing - leaving the convention true of the files the original work touched and false of the rest of the tree. Two passes, on the same lines and so landing together: - 366 bare references gain their repo. All 77 distinct numbers were resolved against BOTH repos first: 62 of them exist in each, meaning different things, so the classification is per-occurrence rather than per-number. #188 and #195 are fork mirror issues in the release notes while confluentinc#188 and confluentinc#195 are the upstream bugs cited in test comments in the same tree. - 24 `upstream #NNN` uses become the owner form. That form passed the gate but names a relationship rather than a repository, and this fork is itself upstream to anyone who forks it. Three sets are deliberately NOT prefixed, because they are not references: author ordinals ("run #1", "produce #1/#2", "NUDGE #1/#2") annotating log excerpts, reworded to plain numbers; the changelog gate's fixture, which asserts that a *bare* #NN is not a citation and would have been destroyed by qualifying it, so it moves above the threshold as a fake #999104; and upstream-pr-analysis.adoc, which is exempt and written entirely in upstream terms. README link text keeps its qualifier even though the URL beside it already names the repo - the gate can see a link target, a reader cannot, and this fork has its own #12. Quoted upstream titles keep the quotation intact with the number appended rather than having the owner inserted mid-title. README is generated: the edit is in src/docs/README_TEMPLATE.adoc. @tag("#355") becomes @tag("confluentinc#355"). Verified nothing selects on that tag - no pom, workflow or script filters it - and both classes still collect and pass. The 14 upstream-derived Java files gain the "Modifications Copyright" line the provenance-aware header check requires of any file changed since the fork point. docs/inflight/next-qualify-remaining-refs.md is deleted: this is everything it tracked, and in-flight files do not outlive their work. No behaviour change.
astubbs
added a commit
that referenced
this pull request
Aug 7, 2026
The reference gate requires any #NNN below the threshold to name its repo, because the fork's numbering sits entirely inside upstream's range and a bare number is a coin flip. It checks added lines only, so it never fired on text nobody was editing - leaving the convention true of the files the original work touched and false of the rest of the tree. Two passes, on the same lines and so landing together: - 366 bare references gain their repo. All 77 distinct numbers were resolved against BOTH repos first: 62 of them exist in each, meaning different things, so the classification is per-occurrence rather than per-number. #188 and #195 are fork mirror issues in the release notes while confluentinc#188 and confluentinc#195 are the upstream bugs cited in test comments in the same tree. - 24 `upstream #NNN` uses become the owner form. That form passed the gate but names a relationship rather than a repository, and this fork is itself upstream to anyone who forks it. Three sets are deliberately NOT prefixed, because they are not references: author ordinals ("run #1", "produce #1/#2", "NUDGE #1/#2") annotating log excerpts, reworded to plain numbers; the changelog gate's fixture, which asserts that a *bare* #NN is not a citation and would have been destroyed by qualifying it, so it moves above the threshold as a fake #999104; and upstream-pr-analysis.adoc, which is exempt and written entirely in upstream terms. README link text keeps its qualifier even though the URL beside it already names the repo - the gate can see a link target, a reader cannot, and this fork has its own #12. Quoted upstream titles keep the quotation intact with the number appended rather than having the owner inserted mid-title. README is generated: the edit is in src/docs/README_TEMPLATE.adoc. @tag("#355") becomes @tag("confluentinc#355"). Verified nothing selects on that tag - no pom, workflow or script filters it - and both classes still collect and pass. The 14 upstream-derived Java files gain the "Modifications Copyright" line the provenance-aware header check requires of any file changed since the fork point. docs/inflight/next-qualify-remaining-refs.md is deleted: this is everything it tracked, and in-flight files do not outlive their work. No behaviour change.
astubbs
added a commit
that referenced
this pull request
Aug 25, 2026
…e context type's day-one shape The review's API-contract and disclosure findings (#12, #13, #14). - The transactional CONTINUE's abort lane recovers only the input side: outputs already produced into the aborted transaction are never visible and are not re-produced - completed work has no replay machinery - so continuing across an abort is at-most-once for those outputs. That was stated honestly only in an integration test's javadoc while the public options javadoc presented the abort as safe. The disclosure now lives in the PERIODIC_TRANSACTIONAL_PRODUCER javadoc (flowing into the generated README), the README feature section as a WARNING, and the feature data's boundaries - with the alternative named: the default shutDown() policy replays the work on restart. - CommitFailureContext.attemptsMade widens to long, matching its only producer (OffsetCommitBudgetExceededException); the silent clamp at the call site is gone. - CommitFailureContext.offsets is defensively wrapped unmodifiable in the builder itself, so the immutability contract holds for any caller of builder(), not just PC's one production call site - the same contract its sibling exception already keeps. 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
… a record that waited out a replacement behind the restored offsets The replay-integrity findings #1, #5, #9, #10 and #12 of the #410 review, resolved as one contract: recovery owes the replay of the aborted transaction's work until the replay has completed, and a record dispatched before that replay re-queues behind what it put back. Each mechanism has a test that was red against the previous code, run as a mutant of this commit. What changed for a user of the PC-built transactional path: - A throw inside the recovery drain no longer lets the next commit publish offsets for output the broker discarded. beginReplacement consumed the pending condition before the drain and replay ran; a successful-work listener (user code, run by the drain) throwing there was logged as "attempted again on a later pass", but the next pass found nothing pending, built the replacement at once, and its first commit trimmed the intact ledger. ProducerManager now carries replayOwed, set beside the consumed condition and cleared only when the drain and replay have returned normally; completeReplacement defers while it is set, and the recovery pass re-enters the write lock whenever it is set, condition or no condition. PartitionState forgets a ledger entry only after every entry is back in processing, and the mailbox drain lands every result before rethrowing the first failure - a throw mid-loop used to leave the results behind it in a local queue, in flight forever (ProducerRecoveryTest: aListenerThrowingDuringTheRecoveryDrainLeavesThe ReplayOwedUntilALaterPassCompletesIt, asserting that every offset the replacement committed has output in the replacement's own history; ProducerManagerRecoveryTest: noReplacementIsBuiltWhileTheReplayIsStill Owed). - Under KEY or PARTITION ordering a record no longer produces ahead of the restored earlier record of its shard. The second record of a key is dispatched once the first completes, and can be on its way to the produce lock - or parked at it - when the replay puts the first back; it used to proceed the instant the replacement was published, and its output landed first. The control thread now stamps every batch with the replay generation at dispatch (it is the thread that also runs the replay, so the two are totally ordered - stamping on the worker would leave a batch queued in the pool across a replay unstamped), and the produce lock refuses a batch whose generation is stale: the read hold is released, the batch fails with ProducerInvalidatedException, and ordered selection takes the restored lower offset first. A replay that put nothing back moves the generation nothing, so a parked worker proceeds as before (ProducerRecoveryTest: aRecordDispatchedBeforeTheReplay ProducesAfterTheRestoredEarlierRecordOfItsKey, in eager mode so the record is held in its user function with no lock across the fence; ProducerManagerRecoveryTest: aWorkerDispatchedBeforeAReplayIsRefusedThe ProduceLockAfterIt and its control arm). - Recovery is now silent at the record level, as the plan's settled decision said it was. A batch that could not be produced because the producer was being replaced took the same arm as a user-function failure, so RecordContext.getNumberOfFailedAttempts() rose by one per recovery, the retry delay applied, and a dead-letter-after-N policy could dead-letter a live record once per rebuild-and-refence cycle. WorkContainer.deferForRecovery() ends the delivery with no attempt counted, no retry delay and no last-failure reason; the failed-records meter does not count it; and the container goes back into selection without entering the retry queue, which reads an absent retry deadline as Instant.MIN and overflowed the control thread's lowest-retry-time calculation the first time a deferred record reached it. Recorded as a dated correction beside the decision in the plan's Key Technical Decisions (ProducerRecoveryTest: aRecordDeferredForRecoveryCarriesNo FailedAttemptAndCountsOnNoFailureMeter). - The drain-before-replay order is pinned. The pair is extracted into a package-visible replayWorkDiscardedByAbortedTransaction(), and AbortedTransactionReplayStepTest mailboxes a completed result without draining, calls it, and asserts both offsets are restored; with the drain removed it returns 1 and offset 1 stays complete. - The broker IT fences on a NON-empty ledger too. The existing case initialises the rogue only after every prior key is visible at read_committed, so its ledger is always empty when the fence lands and the replay never runs on the wire. The new case holds a processed phase uncommitted under a 10 s commit interval, asserts the verifier has seen none of it, then fences: every key's user function runs at least twice and exactly one result per key is visible after a settle poll, which both cases now run before asserting "exactly one". TransactionalClaim C15's proof text names the new case for the replay half. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VrpH51xNDodaajE4P2nhFg
astubbs
added a commit
that referenced
this pull request
Sep 2, 2026
…ts, the rest of the commit before this The previous commit (f8ed2bb) was meant to carry all of this; a pre-commit gate stopped the command before it staged these files, and the history-rewrite hook forbids amending under an in-progress review. Its message, which describes both commits together: The replay-integrity findings #1, #5, #9, #10 and #12 of the #410 review, resolved as one contract: recovery owes the replay of the aborted transaction's work until the replay has completed, and a record dispatched before that replay re-queues behind what it put back. Each mechanism has a test that was red against the previous code, run as a mutant of this commit. What changed for a user of the PC-built transactional path: - A throw inside the recovery drain no longer lets the next commit publish offsets for output the broker discarded. beginReplacement consumed the pending condition before the drain and replay ran; a successful-work listener (user code, run by the drain) throwing there was logged as "attempted again on a later pass", but the next pass found nothing pending, built the replacement at once, and its first commit trimmed the intact ledger. ProducerManager now carries replayOwed, set beside the consumed condition and cleared only when the drain and replay have returned normally; completeReplacement defers while it is set, and the recovery pass re-enters the write lock whenever it is set, condition or no condition. PartitionState forgets a ledger entry only after every entry is back in processing, and the mailbox drain lands every result before rethrowing the first failure - a throw mid-loop used to leave the results behind it in a local queue, in flight forever (ProducerRecoveryTest: aListenerThrowingDuringTheRecoveryDrainLeavesThe ReplayOwedUntilALaterPassCompletesIt, asserting that every offset the replacement committed has output in the replacement's own history; ProducerManagerRecoveryTest: noReplacementIsBuiltWhileTheReplayIsStill Owed). - Under KEY or PARTITION ordering a record no longer produces ahead of the restored earlier record of its shard. The second record of a key is dispatched once the first completes, and can be on its way to the produce lock - or parked at it - when the replay puts the first back; it used to proceed the instant the replacement was published, and its output landed first. The control thread now stamps every batch with the replay generation at dispatch (it is the thread that also runs the replay, so the two are totally ordered - stamping on the worker would leave a batch queued in the pool across a replay unstamped), and the produce lock refuses a batch whose generation is stale: the read hold is released, the batch fails with ProducerInvalidatedException, and ordered selection takes the restored lower offset first. A replay that put nothing back moves the generation nothing, so a parked worker proceeds as before (ProducerRecoveryTest: aRecordDispatchedBeforeTheReplay ProducesAfterTheRestoredEarlierRecordOfItsKey, in eager mode so the record is held in its user function with no lock across the fence; ProducerManagerRecoveryTest: aWorkerDispatchedBeforeAReplayIsRefusedThe ProduceLockAfterIt and its control arm). - Recovery is now silent at the record level, as the plan's settled decision said it was. A batch that could not be produced because the producer was being replaced took the same arm as a user-function failure, so RecordContext.getNumberOfFailedAttempts() rose by one per recovery, the retry delay applied, and a dead-letter-after-N policy could dead-letter a live record once per rebuild-and-refence cycle. WorkContainer.deferForRecovery() ends the delivery with no attempt counted, no retry delay and no last-failure reason; the failed-records meter does not count it; and the container goes back into selection without entering the retry queue, which reads an absent retry deadline as Instant.MIN and overflowed the control thread's lowest-retry-time calculation the first time a deferred record reached it. Recorded as a dated correction beside the decision in the plan's Key Technical Decisions (ProducerRecoveryTest: aRecordDeferredForRecoveryCarriesNo FailedAttemptAndCountsOnNoFailureMeter). - The drain-before-replay order is pinned. The pair is extracted into a package-visible replayWorkDiscardedByAbortedTransaction(), and AbortedTransactionReplayStepTest mailboxes a completed result without draining, calls it, and asserts both offsets are restored; with the drain removed it returns 1 and offset 1 stays complete. - The broker IT fences on a NON-empty ledger too. The existing case initialises the rogue only after every prior key is visible at read_committed, so its ledger is always empty when the fence lands and the replay never runs on the wire. The new case holds a processed phase uncommitted under a 10 s commit interval, asserts the verifier has seen none of it, then fences: every key's user function runs at least twice and exactly one result per key is visible after a settle poll, which both cases now run before asserting "exactly one". TransactionalClaim C15's proof text names the new case for the replay half. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VrpH51xNDodaajE4P2nhFg
Draft
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
vertx.versionfrom 4.2.7 to 4.3.1.Updates
vertx-web-clientfrom 4.2.7 to 4.3.1Updates
vertx-junit5from 4.2.7 to 4.3.1Dependabot 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 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)