Skip to content

build(deps): bump junit-pioneer from 1.7.0 to 1.7.1 - #13

Closed
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1
Closed

dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github May 25, 2022

Copy link
Copy Markdown

Bumps junit-pioneer from 1.7.0 to 1.7.1.

Release notes

Sourced from junit-pioneer's releases.

v1.7.1

Changelog generated by Shipkit Changelog Gradle Plugin

1.7.1

Commits

Dependabot compatibility score

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 rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will 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 version will 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 dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [junit-pioneer](https://github.com/junit-pioneer/junit-pioneer) from 1.7.0 to 1.7.1.
- [Release notes](https://github.com/junit-pioneer/junit-pioneer/releases)
- [Commits](junit-pioneer/junit-pioneer@v1.7.0...v1.7.1)

---
updated-dependencies:
- dependency-name: org.junit-pioneer:junit-pioneer
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added the dependencies Pull requests that update a dependency file label May 25, 2022
@astubbs astubbs closed this Oct 20, 2022
@dependabot @github

dependabot Bot commented on behalf of github Oct 20, 2022

Copy link
Copy Markdown
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 @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

@dependabot
dependabot Bot deleted the dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1 branch October 20, 2022 16:05
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
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant