Skip to content

test(core): act on the inactive-test audit - the tests that did not run, assert or exist now do - #264

Merged
astubbs merged 50 commits into
masterfrom
test/inactive-test-remediation
Aug 13, 2026
Merged

astubbs merged 50 commits into
masterfrom
test/inactive-test-remediation

Conversation

@astubbs

@astubbs astubbs commented Aug 7, 2026 •

Copy link
Copy Markdown
Owner

Description

Acts on the audit in #263. That PR is merged, so this one is no longer
stacked
- it targets master directly, and master's io.confluent.* → bz.stub.* rename
(#294) is merged in.

All nine of the plan's units. The last three were blocked on #260; it
merged, so they are finished here rather than left as follow-on.

What landed

Five codecs that were silently unchecked are now asserted. OffsetEncoding has 12 values. Four
were skipped by an assumption, five were branched around by a helper called assumeWorkingCodec that
was really return !encodingsThatFail.contains(encoding) - a predicate wearing an assumption's name -
and only three ran the full assertion path. The test read as covering every codec and materially
checked a quarter of them.

The five are not broken: the four v1 codecs (BitSet, BitSetCompressed, RunLength,
RunLengthCompressed) encode length as a short and overflow past 32,767 against this test's 72,770
offsets, and uncompressed BitSetV2 exceeds the max metadata size. The overflow guards are named
where they actually live - Short.MAX_VALUE in BitSetEncoder's initV1, and
MathUtils.toShortExact in RunLengthEncoder.serialise() - and not BitSetEncoder.MAX_LENGTH_ENCODABLE
(v2 only) or OffsetRunLength (decode side, no overflow detection), which an earlier draft of that
javadoc cited. Graceful degradation is what the test is named for, so the fix is to assert the
degradation, not to skip it. The degraded contract - observed, not guessed - is work is repeated,
nothing is lost
.

Also cleans up the same test's assertion hygiene: the vacuous doesNotContain(2500L) is gone (2500 is
never a record offset there, so it passed for working and failing codecs alike - same defect class as
docs/solutions/test-flakiness/vacuous-await-condition-brokerpoller-backpressure-2026-07-31.md), the
tautological doesNotContainSequence(expected) that sat behind an exact-contents assertion is gone,
and three checkpoints that re-verified state nothing between them could have mutated are collapsed
into one.

The last JUnit 4 is gone from the test compile path. OffsetEncodingTests used org.junit.Assume
with Hamcrest matchers, working only by accident of junit4 arriving transitively via Testcontainers;
CoreAppMetricsIntegrationTest used org.junit.Assert with its expected/actual arguments reversed.
Both now AssertJ. A tree-wide grep for org.junit.{Assert,Assume,Test,Before,After,Rule} imports
returns nothing. This is a prerequisite unblocker for the JUnit 6 bump in
#38, not a conflict with it.

Four dead tests deleted - a stub that never ran green and could not have
(VertxTest.handleHttpResponseCodes, body assertThat(true).isFalse() behind @Disabled), a
commented-out @Test over an infinite stream (StreamTest.test), an empty {} body
(SampleTestingFailsafePluginInclusionCore), and a log.error with no assertions
(JavaEnvTest). Plus StringTestUtils, which the last of those solely orphaned.

Commented-out alternatives removed - and this analysis was incomplete. See the addendum below. No
live value changed: 30_000_00 is rewritten as 3_000_000, byte-identical at runtime, and every
volume flagged turned out to be already correct, a deliberate increase misread as a reduction, or
gated by a wait that would have to move with it.

One main-source correction, javadoc only. PartitionStateManager.onOffsetCommitSuccess claimed to
truncate tracked offsets below the committed offset. It does not, and cannot: PartitionState tracks
only incomplete offsets and the committed offset is the lowest incomplete one, so there is nothing
below it to throw away. The truncation that does exist happens on the bootstrap poll. Found while
re-deriving what the two dark core tests should assert; no behaviour changed.

The audit itself corrected, including four claims it had inherited from its 2026-04-22 predecessor
without re-verifying them, and all ten never-written stubs given a disposition.

The finding worth reading

Of the ten tests deleted rather than written, only one is still worth writing.

Bucket Count
Write it 1 - userSucceedsButProduceToBrokerFails
Already covered under another name 5 - each now cited
Feature never existed 3
Obsolete by construction 1

The three that cannot be written are the interesting ones. Parallel-consumer has never had a
dead-letter queue
- zero occurrences in any src/main/java - and it is the most-demanded missing
feature, already tracked as #149. maxPerPartition and maxPerTopic were
written as a trio with maxOverall; only the global scope was ever built, and it is
WorkManagerTest.maxInFlight today. So those stubs record an aspiration for limits at three scopes, of
which one shipped.

The three units that were blocked are now done

#260 was the hard prerequisite - it rewrites both files these touch and
collapses the repeat base-offset commits they would otherwise assert on. It merged, so the two
long-dark tests are re-enabled and the missing one is written, here.

Both dark tests had been @Disabled since 2020 and failed 100% deterministically (12 executions,
zero variance). The library is correct - direct measurement shows key-order blocking holding
exactly. The tests were wrong, in the same way twice: a committed offset is exclusive, so it
names where to resume, not the last record done.

  • offsetsAreNeverCommittedForMessagesStillInFlightLong asserted that nothing commits while
    work is in flight, via verify(producerSpy, after(...).never()).commitTransaction(). PC does commit
    the base offset; that is a starting point, not progress. Now asserts the frontier, cumulatively:
    {}, {}, {3}, {3,4}, {3,4,6}.
  • processInKeyOrder asserted a flattened {0, 2, 3, 6, 8}. Two things were wrong: the exclusive
    offset above, and partition 1's base offset of 4, which the flattened assertCommits reads as
    progress because it only trims a genesis of 0. Now per-partition - one assertCommitLists
    checkpoint, then frontier assertions ending at p0=4, p1=9. The frontier rather than the exact
    set is a follow-up correction: the exact-set form passed locally and failed in CI, because which
    intermediate offsets appear depends on where the wall-clock commit tick falls relative to work
    completing ([1, 3] on a slow runner, [3] on a fast one). That is the same trap
    test(core): tolerate PC's repeat commit of the same base offset #260 fixed for repeat commits, in a different shape. The frontier is the
    real invariant: it can only move when work completes contiguously.
  • userSucceedsButProduceToBrokerFails is new. The produce half of produceMessageFlow: the user
    function succeeds and the produce that follows it fails. It asserts the consequence, not the throw -
    the offset does not advance and the record is retried. No producer-callback-thread variant; that
    asymmetry is owned by open fix(core): stop a terminally failed send from publishing half a result set under transactions #261 and is unreachable in this harness anyway.

All three run across all three CommitModes, and each was mutation-checked: breaking the expected
value reds it.

Addendum: the commented-out analysis asked the wrong question

Review of this PR objected to the deletions at nine sites. Re-tracing each one shows the objection
lands, and shows why: the deletions asked whether a commented-out line was dead, and never asked
whether it had ever been alive.

That is the question that decides what the line is. A line that was never live is more likely to
record a manual run, not less - uncommenting a rung, running it, and commenting it back leaves nothing
in git, so the parked ladder is the only place the volumes someone actually exercised are written
down. A superseded live value is the opposite: history already holds it.

Line Ever live? What it is
MultiInstanceHighVolumeTest //10_000_000 yes - live at 04cd4d81, commented at ad3636a5 residue; traced correctly
StreamTest //@Test no - born commented at 61f4c0e4 infinite loop; no procedure to recover
VeryLargeMessageVolumeTest //2_000_000 no - added at 2b0ab66b as the live value was lowered an aspiration; the audit said so, this PR's commit called it "stale"
LoadTest 8_000_0 / 4_000_00 / 4_000_0 / 8 no - all four born commented at af1fa5de an authored range, 8 to 400,000; nothing was traced
TransactionAndCommitModeTest 2 / 100 / 1000 no - born commented at 2b0ab66b a concurrency ladder bracketing the live value; nothing was traced

Two more of the same shape. JavaEnvTest's javadoc said it was "used to manually inspect the java
environment at runtime - particularly useful for CI environments"
- a manual diagnostic, deleted for
asserting nothing, which removed the tool without automating what it was for. And
VertxTest.handleHttpResponseCodes was called "a deletion candidate... nothing here to restore"; true
of the stub, silent about the gap - send.onSuccess calls onUserFunctionSuccess, and a WebClient
future succeeds on any HTTP response, so a 5xx appears to commit the offset, untested either way.

The provenance is recorded as a dated addendum in audit §11 rather than by rewriting the 2026-08-08
claims, per docs/citations.md.

The recovery, and what running it found

Each ladder comes back as a system-property knob - -D<concern>.<knob>, matching the existing
chaos.seed and ambient.probe - rather than as restored comments: LoadTest.RECOVERED_VOLUMES
(-Dload.total), a -Dtransactions.concurrency ladder in TransactionAndCommitModeTest,
-Dvolume.messages in VeryLargeMessageVolumeTest, and -Dmultiinstance.messages in
MultiInstanceHighVolumeTest.

A fixed deadline was the mechanism at five of five sites. Not a quirk of one test: it is how
these procedures stopped being runnable. Someone parks a higher rung, the hard-coded wait fails it
regardless of whether the run is healthy, the rung becomes decoration, and the next reader deletes it
as dead. MultiInstanceHighVolumeTest says so in its own history - the volume was reduced because
"the 60s wait below cannot be met at higher volumes". Every ceiling now derives from the size, anchored
so the gating value is provably unchanged: exactly 60s at LoadTest's 4,000, multiplier exactly 1 at
64 threads, exactly 120s at 1M, exactly 60s at 3M. Pinned in milliseconds by CompletionCeilingTest (4
tests, no Docker) rather than only by Docker-bound integration runs.

Two rungs abandoned as unreachable both pass on first attempt. VeryLargeMessageVolumeTest at the
2,000,000 someone wanted in 2020: green in 22.5s. MultiInstanceHighVolumeTest at the 10,000,000
reduced away in 2021: green in 62s. Nothing was too ambitious - the constraint dissolved as hardware
got faster, and nobody rechecked because the only record of the intent was a comment nobody executes.

One rung could never have run, and only executing it showed that. LoadTest's parked 8 derives
its key range as volume / 100, so eight records gave zero keys and publishMessages threw
IndexOutOfBoundsException on the first send - true of af1fa5de as authored. So "born commented
means someone ran it by hand" holds for the volume rungs and fails for this one. Provenance narrows
what a parked line was; it does not settle it. The key range is floored at one, and the setting now
does what it was for.

Two exposures are stated rather than hidden. LoadTest gains
asyncConsumeAndProcessAtVolume, @Tag("performance") - but that tag is not opt-in:
bin/performance-test.sh passes -Dincluded.groups=performance and is the required "Performance
Tests" leg of maven.yml, so it runs on every PR at 40,000, ten times the gating volume, with no
retry. LoadTest is a listed 1/20 undiagnosed member of the load-tightness flake family at the
gating volume (docs/inflight/test-load-tightness-flakes.md); the rate at 40,000 has never been
measured. And the top recovered rung, -Dload.total=400000, derives a 100-minute ceiling against
CI lanes that cap at 60, so it must be run outside them or the job timeout raised first - inside,
a genuinely hung run is killed 40 minutes before the diagnostic ConditionTimeoutException fires. Both
are stated in the javadoc; the first is left open for a human call in
docs/inflight/pr-263-264-inactive-test-stack.md.

JavaEnvTest's environment dump is automated into the AMBIENT PROBE AUTOPSY block, where
AGENTS.md already sends a reader when a broker integration test fails - correlated with the failure,
which the manual version never was. It is emitted once per JVM, not once per run: the integration
lane forks several, so a run can carry one dump per fork. Because the autopsy goes straight to CI logs,
values of properties whose key reads like a credential (password, secret, token, apikey, …)
are masked while the key still prints - nothing in this repo passes a secret as -D today, so this
stops a future one rather than fixing a present leak. Masking by name beats an allowlist, which would
silently drop the next knob somebody adds.

The Vert.x gap is asserted. A delivered 500 marks the record processed and commits the offset
(serverErrorStatusStillCommits); a transport failure retries it
(transportFailureIsDistinctFromANonSuccessStatus). Both halves pinned, and the contract stated on
VertxParallelEoSStreamProcessor where someone configuring a WebClient will meet it.

A pre-existing flake in AmbientProbeExtensionTest is fixed on the way past. Every
buildAutopsy call mutates the same static once-per-JVM dump guard whether or not the test cares
about it, and this module runs JUnit thread-parallel outside -Pci, so any two unserialised calls
could red each other. Every test that calls buildAutopsy now holds the same @ResourceLock, not
just the ones asserting on the dump.

Documentation lifecycle

  • The three landed plan documents are deleted (2026-08-08-001, 2026-08-08-002,
    2026-08-12-001): their work landed, and AGENTS.md says a plan goes stale once its work lands. The
    one thing that outlived them - the measured commit sequences for the three formerly-blocked units -
    is now in those tests as assertions with the reasoning in comments, rather than as a prose copy
    that would drift.
  • The LargeVolumeInMemoryTests OOM diagnostics are salvaged into docs/test-hardening/. They
    existed only on origin/refactor/test-hardening, which is on the safe-to-delete list, and they are
    the sole measured evidence that restoring 1M exhausts the heap in the close path.
    docs/refactoring.md now scopes that restore as three changes, not one.
  • docs/todo-index.md no longer carries a marker count, and the count is removed from the
    generator bin/todo-index.sh, not just from the generated file - a second, drifting statement of
    what the list below already says exactly. The script still prints one to the console, where it
    cannot go stale.
  • docs/inflight/pr-263-264-inactive-test-stack.md records the stack's state, the ten rename
    conflicts and how they went, and the open items.

Verification

CI is green on 970c521, every required check included. Core unit suite 347 tests, 0 failures, 8
skipped
. Vertx module 18 tests, 0 failures. OffsetEncodingTests steady at 18 run / 0 failures
/ 4 skipped
before and after, so the assumption migration is like-for-like. todo-index --check,
copyright headers, docs-data and quarantine registry all pass.

Every recovered knob was executed, not merely made selectable: LoadTest in the gating lane and under
-Dincluded.groups=performance and at -Dload.total=8; the concurrency ladder at 64 and at 2; the
volume ladders at 5,000 / 1M / 2M and 3M / 10M. Anti-vacuity control: each run logs its own count
(8/8, 4000/4000, Producing 10000000 messages) and the concurrency runs log maxConcurrency=64 /
maxConcurrency=2, so the properties demonstrably drive the runs rather than merely being accepted.

Now established: AGENTS.md asks which cause was determined before a timeout moves - contention or
a genuine concurrency bug. The uncontended-broker diagnostic has since been run at the 40,000 rung:
5/5 green at ~52s against its derived 600s ceiling, so the code is sound at that volume and nowhere
near its deadline. By that rule this family's failures are contention. What the measurement could not
clear - the lane shares one fork, one heap and an unused Postgres container - is recorded in
docs/inflight/test-required-perf-lane-scope.md.

Anti-vacuity control: mutating two terms of the new degraded assertions reds exactly the 5
degraded parameters and nothing else
- so the new assertions can fail for the right reason, rather
than merely being green.

Nothing was weakened to get green. The one assertion removed for weakness was the vacuous one, and it
was replaced with a strictly stronger positive check.

Review round: four P1s found and fixed

A seven-reviewer pass over this PR found four P1s. Two were reproduced by running the tests rather
than reading them, and both were introduced here:

  • The sibling test asserted the commit tick path. offsetsAreNeverCommittedForMessagesStillInFlightLong
    pinned the exact commit history, which failed 3 of 10 runs - [1, 3] where [3] was expected and
    [3, 4, 5, 6] where [3, 4, 6] was, in two commit modes. Both are correct PC behaviour. This is the
    defect this PR documents and fixes in processInKeyOrder, applied to one test and not its sibling
    twenty lines away. Now on the same awaitFrontier treatment: 12/12 clean on the full-class runs
    that previously failed 3 of 10.
  • processInKeyOrder point-checked processedState.get(2) where the worker writes it after waking;
    failed 1 of 10 runs. Now awaited, matching what the same test already did for records 5 and 6.
  • Two documented knob commands selected zero tests and exited BUILD SUCCESS - both classes are
    @Tag("performance"), the default excluded.groups contains it, and exclusion beats inclusion. Both
    now use bin/performance-test.sh. The pom.xml comment this PR added said "or -Dexcluded.groups="
    and taught the same trap; it now says BOTH.
  • redact() masked on the key only, so a credential inside a value under an innocuous key printed
    verbatim to CI logs. It now scans values too, and passphrase is a marker. NOT pat, which was
    suggested: it substring-matches java.library.path and would blank most of the dump. A test pins that.

Two corrections to this PR's own claims came out of the same pass. The perf-lane javadoc blamed
<parallel>methods</parallel> for contention; Surefire's JUnit Platform provider never reads that
element and -Pci disables parallelism anyway, so the lane is sequential in one fork and the first
suspects are heap and the 60-minute cap. And awaitForCommitExact(int,int) was left dead by this PR's
own rewrite - it verified sendOffsetsToTransaction, so it only ever worked under one of the three
commit modes - and is deleted.

Deferred deliberately, with reasoning recorded rather than lost:
docs/inflight/test-inactive-test-review-followups.md (chiefly hoisting awaitFrontier into the shared
test base, and giving its negative checkpoints a hold rather than a sample) and
docs/inflight/test-required-perf-lane-scope.md.

Checklist

  • Docs updated - the audit, docs/refactoring.md, the inflight stack note, and the generated
    todo index
  • User-facing feature documentation data added under docs/features/ - N/A - no new
    user-facing feature; the Vert.x status-code contract was already the behaviour and is now stated
    in VertxParallelEoSStreamProcessor's javadoc
  • Tests added/updated
  • Title & body reflect the final content of this PR
  • Self-hosted runner / security implications considered - no workflow or runner config is touched,
    but two things are worth a reviewer's eye: the ambient probe now dumps system properties into CI
    logs (values masked by credential-looking key name), and asyncConsumeAndProcessAtVolume runs
    automatically in the required Performance Tests leg at ten times the gating volume

astubbs and others added 7 commits August 8, 2026 02:23
Answers four questions with per-test evidence: 5 tests are @disabled (not the
7 a raw grep returns - one hit is javadoc, one is a @DisabledOnOs platform
guard), 1 has an empty body, 4 are placeholders, and 4 more were deleted rather
than implemented by confluentinc#493 while the branch that would have written
them never merged.

Only 1 of the 5 disabled tests records why. The two core ones were both
disabled by c1fefbc "Create and commit offset map" in 2020 and have been dark
since; the real gap is the end-to-end per-CommitMode assertion that offset
commits respect key-order blocking.

Also records two categories nobody asked about because an annotation grep
cannot see them: 15 of 289 tests assert nothing, and OffsetEncodingTests
reports green with most of its assertions branched away by a helper named
assumeWorkingCodec that is not an assumption.

Absorbs docs/test-hardening/disabled-and-weakened-tests-audit-2026-04-22.md,
which existed only on the unmerged refactor/test-hardening branch, and corrects
the two reasons its own git history refutes. Findings are keyed by class and
method rather than line number - that predecessor's line numbers had drifted
~22 lines in four months.

Records only. No test behaviour, assertion, timeout or volume is changed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SizQDD2hVUjD7EhESe9Hkb
A 455-line audit of disabled, kneecapped and weakened tests sat unread on
refactor/test-hardening for four months. Not because it was wrong - because
docs/refactoring.md described that branch by its OTHER commit ("OOM diagnostics
for LargeVolumeInMemoryTests at 1M") and never mentioned the audit, while
docs/inflight/branch-stale-and-diagnostic.md filed the branch under Superseded,
i.e. safe to delete. The only copy of unique content was on the delete list,
indexed under a description that did not describe it.

Both entries now say what the branch actually holds and where the content went.
The branch is genuinely safe to delete once its 1M/OOM commits are salvaged.

Also corrects the origin/refactor/empty-tests entry: its removal half landed on
master via confluentinc#493, so only the implement half is still open, and the
four tests it would restore are now named.

Adds the deferred work the audit found to the refactoring backlog - the
@timeout(60000L) unit bug, the assumeWorkingCodec misnomer, the JUnit 4
Assume on the Jupiter classpath, and the key-order commit coverage gap - plus
an AGENTS.md pointer so the next agent finds docs/test-hardening/ without
knowing it exists.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SizQDD2hVUjD7EhESe9Hkb
An independent falsification pass against the audit found the evidentiary spine
sound - every git attribution survived, including the two hardest - but the
counting was not publishable. Corrected here:

- confluentinc#493 deleted TEN tests, not four. The six omitted were the most
  substantive intent in the commit: dead-letter queue, retry ordering, and
  in-flight backpressure. Also names confluentinc#494, the second follow-up
  that never merged, and records that only 3 of the 10 ever got
  NotImplementedException stubs on the restore branch.
- Denominator was 289; it is 292 (301 with @archtest). @CartesianTest
  contributes 3 methods in TransactionAndCommitModeTest and is meta-annotated
  @testtemplate, so "zero @testtemplate" was true only of the literal string.
- LargeVolumeInMemoryTests was recorded as fixed by PR #49. It is NOT fixed:
  master still runs 500 messages with 1_000_000 commented out, and PR #49 never
  touched the file. The predecessor audit carried a caveat to re-check this
  before flagging, and dropping that caveat is how an open defect became a
  closed one. This was the worst error in the document.
- Quarantine script subclasses hold 27 tests, not 29; assumeWorkingCodec has 5
  call sites, not 6; assumption aborts are 5 sites, not 6; the example modules
  have 6 test methods, not 9.
- 9.4 claimed ~15s of unfailable sleep; ProgressBarTest is @disabled and costs
  nothing, so it is ~5s.
- 8.5 refuted a "Short superseded Long" claim the predecessor never made - that
  was a hypothesis raised during investigation, now labelled as such.

Three of the wrong counts came from one habit: counting raw grep hits instead
of enumerating what matched, which is the exact error the document opens by
warning about. The reproduction command has been replaced with one that
enumerates annotation shapes rather than trusting a hard-coded whitelist.

Also stops underselling existing key-order coverage: TransactionAndCommitModeTest
runs the full CommitMode x ProcessingOrder cross-product including KEY. The
central gap claim survives anyway - those tests assert counts, not committed
offsets, and run on one partition.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SizQDD2hVUjD7EhESe9Hkb
…osition

Three research passes changed what the audit says.

The two core tests disabled in 2020 are no longer "no reason recorded". An
abandoned branch, bugs/turn-on-commit-tests @009bb7122, deletes exactly those
two @disabled lines and says why: "Turn back on offset commit tests which were
dibbled when the offset map feature was added". Same author, contemporaneous.
The annotations still carry no message, so 4 of 5 remain undocumented - but the
cause is now evidenced rather than inferred, and somebody had already tried the
cheap un-disable and abandoned it at WIP.

Section 4 is rewritten. Of the ten tests confluentinc#493 deleted, only ONE is
still worth writing: userSucceedsButProduceToBrokerFails. Five were effectively
written under other names, each now cited. Three describe features the library
has never had - there is no dead-letter queue, no per-partition limit and no
per-topic limit anywhere in main source - so they are issue references, not
tests. maxPerPartition and maxPerTopic were written as a trio with maxOverall,
and only the global scope ever shipped; it is WorkManagerTest.maxInFlight today.
The last, truncationOnCommit, is obsolete by construction.

Four claims inherited from the 2026-04-22 predecessor were wrong and are fixed:
the @timeout unit bug is already solved by open #206 (and its 120s beats
the 60s this audit recommended, which would have raced two 45s/50s Awaitility
budgets); 30_000_00 is a reduction from 10M, not a 30M typo; VeryLargeMessage-
VolumeTest was never kneecapped; and roundsAllowed masks nothing - it is dead.
LoadTest is untagged, so it runs in the gating lane rather than being excluded.

Salvages the LargeVolumeInMemoryTests OOM diagnostics, which existed only on a
branch marked safe-to-delete and are the sole measured evidence that restoring
1M exhausts the heap in the close path.

Corrects PartitionStateManager.onOffsetCommitSuccess's javadoc, which still
described discarding tracked offsets below the committed offset. Nothing is
discarded, and nothing below the committed offset is tracked to discard.
Javadoc only - no behaviour change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SizQDD2hVUjD7EhESe9Hkb
…d anything

- VertxTest.handleHttpResponseCodes: body was assertThat(true).isFalse() behind
  @disabled. Born disabled in 2020, never ran green, could not have. Its
  @disabled import goes with it - it was the only user.
- StreamTest.test: @test commented out over an intact infinite Stream.generate
  printer. The class keeps testStreamSpliterators.
- SampleTestingFailsafePluginInclusionCore: an empty {} body. It was not proving
  failsafe picks up src/test-integration - that source root is added
  declaratively in the root pom by build-helper, and failsafe selects by package
  pattern, which 28 other classes in that package already satisfy.
- JavaEnvTest: one log.error, no assertions, javadoc conceding it is for manual
  inspection. Deleting it orphans StringTestUtils, whose only method it was the
  only caller of, so that goes too.

Core unit suite: 320 tests, 0 failures. All four are absent from the surefire
reports afterwards and no other count moved.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SizQDD2hVUjD7EhESe9Hkb
Every volume the audit flagged turned out to be already correct, a deliberate
increase misread as a reduction, or gated by a wait that would have to move with
it. So this removes the dead alternatives and records why the live values stay.

- MultiInstanceHighVolumeTest: 30_000_00 rewritten as 3_000_000. Byte-identical
  at runtime - the digits were always three million. History shows it was
  REDUCED from 10_000_000, so the commented 10M was the superseded value, not
  the intent; that line goes. Raising it is blocked by a hard-coded 60s wait in
  the same method anyway.
- VeryLargeMessageVolumeTest: drops a stale // 2_000_000. The live value never
  moved - it went 1_000_000 to 100_0000, the same number, to 1_000_000.
- LoadTest: drops four dead alternatives, keeps 4_000, and records why it must
  not be raised casually - it is untagged so it runs in the gating lane, and it
  is a listed member of the load-tightness flake family at this volume.
- TransactionAndCommitModeTest: drops the dead numThreads alternatives and the
  roundsAllowed variable, which was assigned and never read. ProgressTracker is
  built with null rounds and rejects being given both rounds and a timeout, so
  that mechanism was structurally off. The design question its TODO carried is
  real, so it moves to docs/refactoring.md rather than being deleted with it.

TODO index regenerated in the same commit (87 -> 86 markers); --check passes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SizQDD2hVUjD7EhESe9Hkb
…g around

OffsetEncoding has 12 values. Four were skipped by an assumption, five were
branched around by a helper named assumeWorkingCodec that was really
`return !encodingsThatFail.contains(encoding)` - a predicate wearing an
assumption's name - and only three ran the full assertion path. The test read as
covering every codec and materially checked a quarter of them.

The five are not broken: v1 BitSet and RunLength encode length as a short and
overflow past 32,767 against this test's 72,770 offsets, and uncompressed
BitSetV2 exceeds the max metadata size. Graceful degradation is what the test is
named for, so the fix is to assert the degradation rather than skip it.

- assumeWorkingCodec -> isWorkingCodec, and the five call sites gain else
  branches asserting the degraded contract. Observed, not guessed: committed
  metadata is empty, reloaded state resets to zero with only highestSeen
  recovering, and every record from the committed offset up is redelivered. Work
  is repeated, nothing is lost.
- The hard-coded failing list and the switch statement encoded the same
  knowledge; the switch is gone and CODECS_THAT_DEGRADE owns it, with a javadoc
  recording both overflow mechanisms.
- Deletes a vacuous assertion: doesNotContain(2500L), where 2500 is never a
  record offset in this test, so it passed for working and failing codecs alike.
  Replaced with a positive containsExactlyElementsIn(...).inOrder(). Same defect
  class as docs/solutions/test-flakiness/vacuous-await-condition-*.

Also removes the last JUnit 4 from the test compile path - OffsetEncodingTests
used org.junit.Assume with Hamcrest matchers, which only worked by accident of
junit4 arriving transitively via testcontainers, and CoreAppMetricsIntegrationTest
used org.junit.Assert with its expected/actual arguments reversed. Both now
AssertJ. This unblocks the JUnit 6 bump in #38.

Counts unchanged at 18 run / 0 failures / 4 skipped before and after, so the
assumption migration is like-for-like. Anti-vacuity control: mutating two terms
of the new degraded assertions reds exactly the 5 degraded parameters and
nothing else.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SizQDD2hVUjD7EhESe9Hkb
@github-actions

github-actions Bot commented Aug 7, 2026

Copy link
Copy Markdown

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@claude

claude Bot commented Aug 7, 2026 •

Copy link
Copy Markdown

Claude finished @astubbs's task in 15m 54s —— View job


Claude's review of PR #264

  • Gather context (read PR body, diff against origin/chore/audit-inactive-tests, repo CLAUDE.md)
  • Run /code-review:code-review skill against the PR diff
  • Verify load-bearing claims (test counts, anti-vacuity control) where feasible
  • Post findings as inline PR comments
  • Summarize review in this comment

Overall: this is a well-verified PR. Multiple independent review passes (correctness, removed-behavior, reuse, efficiency/altitude) cross-checked the new degraded-codec assertions against the actual encoder/state source (BitSetEncoder, RunLengthEncoder, OffsetSimultaneousEncoder, OffsetMapCodecManager, PartitionState) and found the logic sound — no correctness regressions. The PR's specific claims held up:

  • The removed doesNotContain(2500L) really was vacuous (2500 is never a record offset in the scenario).
  • The Assume→AssertJ Assumptions migration is safe (opentest4j is transitively present via junit-jupiter, so aborts still register as skips, not failures) — and it likely fixes a latent issue, since the old code used JUnit4's Assume with no junit:junit dependency actually on the classpath.
  • The 5-codec/3-codec degrade split (CODECS_THAT_DEGRADE) matches the encoders' real overflow/size-limit behavior.
  • SampleTestingFailsafePluginInclusionCore, JavaEnvTest, and StringTestUtils deletions are all genuinely dead/unreferenced.
  • PartitionStateManager's rewritten javadoc accurately reflects that onOffsetCommitSuccess does not truncate — truncation only happens later, on bootstrap poll.

4 findings posted as inline comments on OffsetEncodingTests.java:

  1. Line 58 — the new javadoc misattributes the v1 short-overflow mechanism to BitSetEncoder#MAX_LENGTH_ENCODABLE (that's actually Integer.MAX_VALUE, gating the v2 path) and to OffsetRunLength (the decode-side class; the real encode-side overflow check is in RunLengthEncoder.serialise). A maintainer following the @link lands in the wrong place.
  2. Line 73 — CODECS_THAT_DEGRADE is a hand-maintained list rather than derived from the encoder's actual output (encoder.getEncodingMap().keySet() is already available and used the same way elsewhere). If a production limit changes, this list can silently drift with no compiler signal.
  3. Line 212 (pre-existing, but re-exposed) — OffsetMapCodecManager.forcedCodec is written under only a READ resource lock, so parallel execution of this parameterized test can race two codec instances against each other. This PR upgrades most branches from tolerant to strict assertions, raising the odds this latent race now surfaces as a flake.
  4. Line 361 — assertDegradedReloadedState(partitionState, FIRST_COMMITTED_OFFSET, highestSucceeded) is called three times in a row (346/361/385) with identical arguments and no intervening state change — dead-weight duplication, not a bug.

All are low-severity (doc accuracy / maintainability / a pre-existing flake risk), not blocking correctness issues.

@github-actions

github-actions Bot commented Aug 7, 2026 •

Copy link
Copy Markdown

✅ Duplicate Code Report

Two engines run in parallel for cross-validation. Each has its own thresholds tuned to its baseline - the real safety net is the per-engine "max increase vs base" check.

✅ PMD CPD

PR Base Change
Clones 28 28 ➖ 0
Duplicated lines 853 850 🫤 +3
Duplication 2.40% 2.39% 🫤 +0.01%
Rule Limit Status
Max duplication 5% ✅ Pass (2.40%)
Max increase vs base +0.1% ✅ Pass (+0.01%)
⚠️ 1 new clones introduced
  • 22 lines (163 tokens): parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java:174 <-> parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java:123 <-> parallel-consumer-vertx/src/test-integration/java/bz/stub/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java:149

✅ jscpd (language-agnostic)

PR Base Change
Clones 75 75 ➖ 0
Duplicated lines 1060 1060 ➖ 0
Duplication 3.04% 3.09% 🙂 -0.05%
Rule Limit Status
Max duplication 5% ✅ Pass (3.04%)
Max increase vs base +0.1% ✅ Pass (-0.05%)
⚠️ 1 new clones introduced
  • 22 lines: parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java:123 <-> parallel-consumer-vertx/src/test-integration/java/bz/stub/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java:149

Powered by astubbs/duplicate-code-cross-check

@github-actions

github-actions Bot commented Aug 7, 2026 •

Copy link
Copy Markdown

📌 Duplicate code detection tool report

The tool analyzed your source code and found the following degree of similarity between the files:

🆕 New file similarities introduced

File A File B Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java parallel-consumer-vertx/src/test-integration/java/bz/stub/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java 31.6
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/AmbientProbeExtension.java parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/AmbientProbeExtensionTest.java 30.3

🔺 Increased similarities

File A File B Base (%) PR (%) Change
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/PartitionState.java parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/PartitionStateManager.java 30.3 33.0 +2.7
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java 55.4 57.2 +1.8
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 62.0 63.3 +1.3
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelStreamProcessor.java 41.7 42.8 +1.1
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 45.9 46.8 +0.9
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/NoEncodingPossibleException.java parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 35.9 36.7 +0.8
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 36.1 36.7 +0.6
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 33.5 34.1 +0.6
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 30.4 30.9 +0.4
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 32.3 32.7 +0.4
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContext.java parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/RecordContextInternal.java 36.0 36.4 +0.4
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelStreamProcessor.java 39.5 39.8 +0.3
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerEarlyCloseTest.java parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerTest.java 54.9 55.2 +0.3
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerSaslAuthenticationTest.java parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerTest.java 46.8 47.0 +0.3
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerCommitTimeoutTest.java parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerEarlyCloseTest.java 70.2 70.4 +0.3
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/AbstractRevokeUnderWorkScenario.java parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosChurnStormIT.java 48.8 49.0 +0.2
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerCommitTimeoutTest.java parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerTest.java 56.5 56.7 +0.2
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelStreamProcessor.java parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 32.9 33.1 +0.2
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerCommitTimeoutTest.java parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerSaslAuthenticationTest.java 49.4 49.6 +0.2
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelStreamProcessor.java parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelStreamProcessor.java 37.1 37.2 +0.1

...and 21 more

Full similarity report
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerException.java 53.72 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java 38.96
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PCRetriableException.java 35.96
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java 35.55
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 34.09
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 34.0
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java 33.47
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 33.23
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelEoSStreamProcessor.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelStreamProcessor.java 61.29 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessor.java 54.98 ⚠️
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 40.27
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelStreamProcessor.java 37.48
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContextInternal.java 32.82
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 31.48
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelStreamProcessor.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelEoSStreamProcessor.java 61.29 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessor.java 51.04 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelStreamProcessor.java 37.19
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 32.46
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContextInternal.java 31.79
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 30.36
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PCRetriableException.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PCRetriableException.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java 35.96
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java 32.53
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerException.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerException.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java 53.72 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java 51.97 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java 43.45
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 33.53
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java 32.72
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalRuntimeException.java 30.71
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerOptions.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerOptions.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/ProducerManager.java 31.58
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessor.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelEoSStreamProcessor.java 54.98 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelStreamProcessor.java 51.04 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelStreamProcessor.java 45.83
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContextInternal.java 34.0
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/AbstractParallelEoSStreamProcessor.java 32.87
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/TestParallelEoSStreamProcessor.java 31.12
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelStreamProcessor.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessor.java 45.83
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelEoSStreamProcessor.java 37.48
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelStreamProcessor.java 37.19
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 33.07
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContext.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContext.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/RecordContextInternal.java 36.43
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContextInternal.java 32.09
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContextInternal.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContextInternal.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessor.java 34.0
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/RecordContextInternal.java 33.33
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelEoSStreamProcessor.java 32.82
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContext.java 32.09
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelStreamProcessor.java 31.79
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/RecordContextInternal.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/RecordContextInternal.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContext.java 36.43
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PollContextInternal.java 33.33
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/AbstractParallelEoSStreamProcessor.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/AbstractParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/BrokerPollSystem.java 33.01
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessor.java 32.87
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/BrokerPollSystem.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/BrokerPollSystem.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/AbstractParallelEoSStreamProcessor.java 33.01
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/ExternalEngine.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/ExternalEngine.java

File Similarity (%)
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java 39.52
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java 59.66 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerException.java 51.97 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java 51.12 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/NoEncodingPossibleException.java 47.79
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalRuntimeException.java 39.76
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java 38.96
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 35.87
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 32.69
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/PCRetriableException.java 32.53
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 31.87
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalRuntimeException.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalRuntimeException.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java 39.76
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java 31.41
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerException.java 30.71
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/PCModule.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/PCModule.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/PCModuleTestEnv.java 32.12
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/ProducerManager.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/ProducerManager.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerOptions.java 31.58
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/ProducerManagerTest.java 30.12
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/utils/Java8StreamUtils.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/utils/Java8StreamUtils.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/utils/JavaUtils.java 35.45
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/utils/CollectionUtils.java 33.31
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/utils/JavaUtils.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/utils/JavaUtils.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/utils/CollectionUtils.java 39.63
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/utils/Java8StreamUtils.java 35.45
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java 50.44 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 36.73
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java 35.87
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 35.81
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java 34.0
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerException.java 33.53
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java 32.12
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java 59.66 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 50.44 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java 48.37
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 46.81
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 45.63
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/NoEncodingPossibleException.java 45.46
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerException.java 43.45
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java 35.55
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalRuntimeException.java 31.41
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/NoEncodingPossibleException.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/NoEncodingPossibleException.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java 47.79
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java 45.46
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java 45.21
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 36.7
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 35.78
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java 51.12 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java 48.37
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/NoEncodingPossibleException.java 45.21
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java 33.47
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerException.java 32.72
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 32.12
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 30.85
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 30.07
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 63.28 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java 46.81
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 36.73
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/NoEncodingPossibleException.java 36.7
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java 34.09
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java 32.69
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java 30.85
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 63.28 ⚠️
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/EncodingNotSupportedException.java 45.63
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 35.81
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/NoEncodingPossibleException.java 35.78
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ExceptionInUserFunctionException.java 33.23
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/InternalException.java 31.87
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/offsets/OffsetDecodingError.java 30.07
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/PartitionState.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/PartitionState.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/PartitionStateManager.java 32.97
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/PartitionStateManager.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/PartitionStateManager.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/WorkManager.java 38.47
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/PartitionState.java 32.97
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/ProcessingShard.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/ProcessingShard.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/ShardManager.java 36.06
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/ShardManager.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/ShardManager.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/ProcessingShard.java 36.06
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/WorkManager.java

📄 parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/WorkManager.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/state/PartitionStateManager.java 38.47
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/AmbientProbeExtension.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/AmbientProbeExtension.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/AmbientProbeExtensionTest.java 30.29
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/DrainingMemberRebalanceIT.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/DrainingMemberRebalanceIT.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/BrokerPollSystemDrainTest.java 30.09
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/KafkaSanityTests.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/KafkaSanityTests.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/utils/LoopingResumingIteratorTest.java 34.29
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java 57.17 ⚠️
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java 43.73
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java 35.53
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java 39.45
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java 38.93
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java 35.53
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/RebalanceEoSDeadlockTest.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/RebalanceEoSDeadlockTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/RebalanceTest.java 36.18
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/RebalanceTest.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/RebalanceTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/RebalanceEoSDeadlockTest.java 36.18
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java 53.88 ⚠️
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java 43.73
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java 38.93
parallel-consumer-vertx/src/test-integration/java/bz/stub/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java 31.62
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionTimeoutsTest.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionTimeoutsTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/ProducerManagerTest.java 30.16
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java 57.17 ⚠️
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java 53.88 ⚠️
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java 39.45
parallel-consumer-vertx/src/test-integration/java/bz/stub/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java 35.24
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/AbstractRevokeUnderWorkScenario.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/AbstractRevokeUnderWorkScenario.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosChurnStormIT.java 49.05
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosRevokeUnderWorkIT.java 35.59
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosChurnStormIT.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosChurnStormIT.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/AbstractRevokeUnderWorkScenario.java 49.05
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosScenarioBase.java 38.09
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosRevokeUnderWorkCooperativeIT.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosRevokeUnderWorkCooperativeIT.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosRevokeUnderWorkIT.java 48.2
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosRevokeUnderWorkIT.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosRevokeUnderWorkIT.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosRevokeUnderWorkCooperativeIT.java 48.2
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/AbstractRevokeUnderWorkScenario.java 35.59
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosScenarioBase.java

📄 parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosScenarioBase.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/chaostests/ChaosChurnStormIT.java 38.09
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/AbstractParallelEoSStreamProcessorTestBase.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/AbstractParallelEoSStreamProcessorTestBase.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/utils/KafkaTestUtils.java 33.2
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessorTest.java 30.08
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/AmbientProbeExtensionTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/AmbientProbeExtensionTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/AmbientProbeExtension.java 30.29
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/BatchTestBase.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/BatchTestBase.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CoreBatchTest.java 30.48
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CheckQuarantineOwnersScriptTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CheckQuarantineOwnersScriptTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/QuarantineLaneReportScriptTest.java 49.69
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/QuarantineRegistryScriptTest.java 47.71
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CommitRejectionTestBase.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CommitRejectionTestBase.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerTest.java 32.52
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerCommitTimeoutTest.java 32.41
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CoreBatchTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CoreBatchTest.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorBatchTest.java 51.93 ⚠️
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyBatchTest.java 50.65 ⚠️
parallel-consumer-vertx/src/test/java/bz/stub/parallelconsumer/vertx/VertxBatchTest.java 44.71
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/BatchTestBase.java 30.48
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerCommitTimeoutTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerCommitTimeoutTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerEarlyCloseTest.java 70.44 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerTest.java 56.73 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerSaslAuthenticationTest.java 49.58
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CommitRejectionTestBase.java 32.41
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerEarlyCloseTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerEarlyCloseTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerCommitTimeoutTest.java 70.44 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerTest.java 55.17 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerSaslAuthenticationTest.java 52.87 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerSaslAuthenticationTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerSaslAuthenticationTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerEarlyCloseTest.java 52.87 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerCommitTimeoutTest.java 49.58
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerTest.java 47.05
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerCommitTimeoutTest.java 56.73 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerEarlyCloseTest.java 55.17 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/MockConsumerSaslAuthenticationTest.java 47.05
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CommitRejectionTestBase.java 32.52
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/ParallelEoSSStreamProcessorRebalancedTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/ParallelEoSSStreamProcessorRebalancedTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessorTest.java 32.91
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessorTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessorTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/ParallelEoSSStreamProcessorRebalancedTest.java 32.91
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/AbstractParallelEoSStreamProcessorTestBase.java 30.08
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/QuarantineLaneReportScriptTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/QuarantineLaneReportScriptTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CheckQuarantineOwnersScriptTest.java 49.69
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/QuarantineRegistryScriptTest.java 33.12
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/QuarantineRegistryScriptTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/QuarantineRegistryScriptTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CheckQuarantineOwnersScriptTest.java 47.71
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/QuarantineLaneReportScriptTest.java 33.12
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/TestConventionsArchTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/TestConventionsArchTest.java

File Similarity (%)
parallel-consumer-vertx/src/test/java/bz/stub/parallelconsumer/vertx/TestConventionsArchTest.java 90.15 ⚠️
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/TestConventionsArchTest.java 89.48 ⚠️
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/TestConventionsArchTest.java 89.48 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/BrokerPollSystemDrainTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/BrokerPollSystemDrainTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/DrainingMemberRebalanceIT.java 30.09
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/PCModuleTestEnv.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/PCModuleTestEnv.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/PCModule.java 32.12
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/ProducerManagerTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/ProducerManagerTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionTimeoutsTest.java 30.16
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/ProducerManager.java 30.12
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/TestParallelEoSStreamProcessor.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/TestParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelEoSStreamProcessor.java 31.12
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/utils/CollectionUtils.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/utils/CollectionUtils.java

File Similarity (%)
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/utils/JavaUtils.java 39.63
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/utils/Java8StreamUtils.java 33.31
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/utils/KafkaTestUtils.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/utils/KafkaTestUtils.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/AbstractParallelEoSStreamProcessorTestBase.java 33.2
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/utils/LoopingResumingIteratorTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/internal/utils/LoopingResumingIteratorTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/KafkaSanityTests.java 34.29
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/offsets/OffsetEncodingBackPressureTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/offsets/OffsetEncodingBackPressureTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/offsets/OffsetEncodingBackPressureUnitTest.java 39.1
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/offsets/OffsetEncodingBackPressureUnitTest.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/offsets/OffsetEncodingBackPressureUnitTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/offsets/OffsetEncodingBackPressureTest.java 39.1
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/truth/CommitHistorySubject.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/truth/CommitHistorySubject.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/truth/LongPollingMockConsumerSubject.java 36.51
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/truth/LongPollingMockConsumerSubject.java

📄 parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/truth/LongPollingMockConsumerSubject.java

File Similarity (%)
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/truth/CommitHistorySubject.java 36.51
parallel-consumer-mutiny/src/main/java/bz/stub/parallelconsumer/mutiny/MutinyProcessor.java

📄 parallel-consumer-mutiny/src/main/java/bz/stub/parallelconsumer/mutiny/MutinyProcessor.java

File Similarity (%)
parallel-consumer-reactor/src/main/java/bz/stub/parallelconsumer/reactor/ReactorProcessor.java 52.05 ⚠️
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyBatchTest.java

📄 parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyBatchTest.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorBatchTest.java 78.98 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CoreBatchTest.java 50.65 ⚠️
parallel-consumer-vertx/src/test/java/bz/stub/parallelconsumer/vertx/VertxBatchTest.java 48.98
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyPCTest.java

📄 parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyPCTest.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorPCTest.java 71.08 ⚠️
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyTest.java

📄 parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyTest.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorTest.java 32.18
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyUnitTestBase.java

📄 parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyUnitTestBase.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorUnitTestBase.java 32.16
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/TestConventionsArchTest.java

📄 parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/TestConventionsArchTest.java

File Similarity (%)
parallel-consumer-vertx/src/test/java/bz/stub/parallelconsumer/vertx/TestConventionsArchTest.java 90.94 ⚠️
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/TestConventionsArchTest.java 90.26 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/TestConventionsArchTest.java 89.48 ⚠️
parallel-consumer-reactor/src/main/java/bz/stub/parallelconsumer/reactor/ReactorProcessor.java

📄 parallel-consumer-reactor/src/main/java/bz/stub/parallelconsumer/reactor/ReactorProcessor.java

File Similarity (%)
parallel-consumer-mutiny/src/main/java/bz/stub/parallelconsumer/mutiny/MutinyProcessor.java 52.05 ⚠️
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorBatchTest.java

📄 parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorBatchTest.java

File Similarity (%)
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyBatchTest.java 78.98 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CoreBatchTest.java 51.93 ⚠️
parallel-consumer-vertx/src/test/java/bz/stub/parallelconsumer/vertx/VertxBatchTest.java 50.2 ⚠️
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorPCTest.java

📄 parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorPCTest.java

File Similarity (%)
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyPCTest.java 71.08 ⚠️
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorTest.java

📄 parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorTest.java

File Similarity (%)
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyTest.java 32.18
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorUnitTestBase.java

📄 parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorUnitTestBase.java

File Similarity (%)
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyUnitTestBase.java 32.16
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/TestConventionsArchTest.java

📄 parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/TestConventionsArchTest.java

File Similarity (%)
parallel-consumer-vertx/src/test/java/bz/stub/parallelconsumer/vertx/TestConventionsArchTest.java 90.94 ⚠️
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/TestConventionsArchTest.java 90.26 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/TestConventionsArchTest.java 89.48 ⚠️
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java

📄 parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java 40.79
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelEoSStreamProcessor.java 40.27
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 39.86
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelStreamProcessor.java 35.63
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelStreamProcessor.java 32.46
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java

📄 parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java

File Similarity (%)
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 39.86
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelStreamProcessor.java 39.8
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelStreamProcessor.java 33.07
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelEoSStreamProcessor.java 31.48
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/JStreamParallelStreamProcessor.java 30.36
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java

📄 parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelStreamProcessor.java 42.8
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 40.79
parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/internal/ExternalEngine.java 39.52
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelStreamProcessor.java

📄 parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelStreamProcessor.java

File Similarity (%)
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java 42.8
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 39.8
parallel-consumer-vertx/src/main/java/bz/stub/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 35.63
parallel-consumer-vertx/src/test-integration/java/bz/stub/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java

📄 parallel-consumer-vertx/src/test-integration/java/bz/stub/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java 35.24
parallel-consumer-core/src/test-integration/java/bz/stub/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java 31.62
parallel-consumer-vertx/src/test/java/bz/stub/parallelconsumer/vertx/TestConventionsArchTest.java

📄 parallel-consumer-vertx/src/test/java/bz/stub/parallelconsumer/vertx/TestConventionsArchTest.java

File Similarity (%)
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/TestConventionsArchTest.java 90.94 ⚠️
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/TestConventionsArchTest.java 90.94 ⚠️
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/TestConventionsArchTest.java 90.15 ⚠️
parallel-consumer-vertx/src/test/java/bz/stub/parallelconsumer/vertx/VertxBatchTest.java

📄 parallel-consumer-vertx/src/test/java/bz/stub/parallelconsumer/vertx/VertxBatchTest.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/bz/stub/parallelconsumer/reactor/ReactorBatchTest.java 50.2 ⚠️
parallel-consumer-mutiny/src/test/java/bz/stub/parallelconsumer/mutiny/MutinyBatchTest.java 48.98
parallel-consumer-core/src/test/java/bz/stub/parallelconsumer/CoreBatchTest.java 44.71

@github-actions

github-actions Bot commented Aug 7, 2026

Copy link
Copy Markdown

✅ SpotBugs Report

No bugs found (new bugs only — baseline from base branch excluded).

astubbs and others added 3 commits August 8, 2026 09:29
The issue-reference gate caught three bare numbers below #1000 on added lines,
and it is right to: the fork's numbering sits inside upstream's range, so a bare
number is a coin flip.

- "PR #49" (twice, in the audit and the backlog) is a fork PR: #49.
- "(#190)" was quoted verbatim from a squashed commit subject, which is exactly
  how an upstream number leaks in looking innocent. Reworded so the quote stops
  at the subject and the number is cited as confluentinc#190 outside it.

bin/check-issue-refs.sh now passes on this branch.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SizQDD2hVUjD7EhESe9Hkb
… test/inactive-test-remediation

# Conflicts:
#	docs/refactoring.md
#	docs/test-hardening/inactive-tests-audit-2026-08-08.md
Same class as the previous commit, three more sites the local gate found once
the audit-branch fix merged up:

- "#149, #160, #236" - the shorthand after the first qualified number
  still reads as a bare reference to the gate, and it is right to: nothing about
  position makes #160 unambiguous.
- The salvaged OOM diagnostics carried "PR #49" verbatim from its branch. A
  salvage is not a reason to import a coin-flip reference, so it is qualified
  here too.
- The plan's dependency diagram had "#106 / #207" for the same reason as
  the first item.

bin/check-issue-refs.sh passes across all 20 changed files.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SizQDD2hVUjD7EhESe9Hkb
@claude

claude Bot commented Aug 8, 2026 •

Copy link
Copy Markdown

Claude finished @astubbs's task in 1m 32s —— View job


Claude's review of PR #264 (re-run after synchronize)

  • Gather context (diff since last review, new commits)
  • Run /code-review:code-review skill against the PR diff
  • Verify load-bearing claims
  • Post findings as inline PR comments (none new — see below)
  • Summarize review in this comment

What changed since the last review: git diff e21a8020..HEAD shows only 4 doc files touched, all mechanical — qualifying bare #NN issue references (#49 → astubbs#49, (#190) → confluentinc#190, #160/#236 → astubbs#160/astubbs#236, #106 / #207 → astubbs#106 + astubbs#207) to satisfy bin/check-issue-refs.sh / the PR Checklist gate. No source files changed.

I checked each edit against its source: astubbs#49 never touched LargeVolumeInMemoryTests (verified in the earlier review pass), (#190) was a squashed-commit subject where the number is upstream (confluentinc#190) not this fork's, and the #160/#236/#106/#207 sites are the same class of ambiguity — a bare number inside the fork's range that could misresolve. All four edits are accurate and I couldn't find any remaining unqualified #NNN (<1000) references in the touched docs (docs/plans/2026-08-08-002-*.md, docs/test-hardening/*.md) by manual grep, consistent with the commit messages' claim that the gate now passes.

Code findings: unchanged from the previous pass, since no code files were touched. The 4 inline comments already posted on OffsetEncodingTests.java (javadoc @links to the wrong overflow mechanism at line 58, hand-maintained CODECS_THAT_DEGRADE list at line 70-73, pre-existing READ-lock/mutation race on forcedCodec at line 212, and the redundant duplicate assertions at lines 361/412) all still apply at the same lines — I re-read each site to confirm nothing moved or was fixed. Not re-posting duplicates since they're already on the PR.

No new findings this pass. Nothing here blocks merge — all outstanding items are low-severity (doc-link accuracy, maintainability, a pre-existing flake risk, test dead-weight).

@astubbs astubbs left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changes needed

astubbs and others added 3 commits August 13, 2026 01:44
…ediation

Brings master in transitively via 263's merge commit f5e72f4, reusing the
conflict resolution already made there.

Repairs stale addresses only: docs/TODO_INDEX.md -> docs/todo-index.md in the
002 remediation plan, following the rename master made. Per docs/citations.md a
dated record's claims are not rewritten, but a reference that no longer resolves
is repaired.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L6PnsPmbwjazSu13M8JYm5
Both branches now have master merged. Records the merge order, the
AGENTS.md and TODO_INDEX rename conflicts already resolved (so they are
not re-litigated), the three units blocked on #260, and two things a
reader would otherwise get wrong: the audit's quarantine count has
drifted since it was written, and the core unit suite was not re-run
locally after the merge.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L6PnsPmbwjazSu13M8JYm5
@github-actions

github-actions Bot commented Aug 12, 2026 •

Copy link
Copy Markdown

🧪🔒 Quarantine Lane Report

Quarantined test Outcome Owner Meaning
PCMetricsTest.metricsRegisterBinding 🔴 failing (expected) #265 quarantine holding
ProducerManagerTest.producedRecordsCantBeInTransactionWithoutItsOffsetDirect 🟡🎲 passed (flapper) #262 proves nothing - passes most runs by nature
OffsetEncodingBackPressureTest.backPressureShouldPreventTooManyMessagesBeingQueuedForProcessing 🟡🎲 passed (flapper) ⚠️ unowned proves nothing - passes most runs by nature

🔴 expected while the owner PR is open · 🟡🎲 flapper, pass proves nothing · 🚨 a deterministic quarantined test passing means its fix landed: delete its @Quarantined annotation + docs/quarantined-tests.md entry (a merge-blocking review thread has been opened). Lane: non-gating; rules: see the Quarantine Audit check.

astubbs and others added 2 commits August 12, 2026 14:23
The plan's R19 asked for a pointer to `docs/test-hardening/` inside AGENTS.md's
`## Testing` section, "in the style of the existing todo-index.md and quarantine
pointers, so the next agent finds it without knowing it exists". What shipped was
only the docs-map table row under "Where things live" - the Testing section, which
is where an agent debugging a dark test actually reads, said nothing about the
audit. The plan's Definition of Done nonetheless claimed the pointer was added.

That is the exact discoverability failure this audit exists to fix: its 2026-04-22
predecessor rotted unread for four months because nothing pointed at it from the
path an agent walks.

Adds the bullet alongside the quarantine one, and names the current dated audit so
the reader lands on a file rather than a directory listing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The handoff note added in 2d5c5b3 cited both PRs as bare `#263`/`#264`, which is
exactly what the PR Checklist issue-ref gate forbids: this fork's numbers sit inside
confluentinc's range, so a bare number is a coin flip on which repo it means. The
gate flagged 13 of them and went red on this PR - a document about the stack's merge
readiness was itself the thing blocking the merge.

Qualifies every reference as `astubbs#NN`, the form the gate strips.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
astubbs and others added 2 commits August 13, 2026 00:36
…failure one that was missing

These were the last three items the stack left open. They were blocked on
#260, which rewrote both files they touch; that merged and is now merged
into this branch, so the blocker is gone and they are finished here rather than
deferred again.

Both dark tests failed 100% deterministically, and in both cases the LIBRARY was
right and the test was wrong.

`offsetsAreNeverCommittedForMessagesStillInFlightLong` asserted, through the
transactional producer spy, that NOTHING commits while work is in flight. PC does
commit - the base offset - which is a statement about where to resume, not
progress. Rewritten onto the mode-agnostic helpers so it means the same thing in
all three commit modes, asserting the frontier cumulatively: {3}, then {3,4},
then {3,4,6}. 3 rather than 2 after 0,1,2 complete, because a committed offset is
exclusive.

`processInKeyOrder` asserted flattened offsets {0,2,3,6,8}. Two separate errors:
the same exclusive-offset confusion, and partition 1's base offset is 4 (record
creation uses a global counter), which the flattened helper cannot tell from
progress because it only trims a genesis of 0. Now asserted per-partition with
assertCommitLists, ending (p0=[3,4], p1=[4,7,9]). The invariant it exists for is
step E: partition 1 will not advance past 4 while key-2's record 4 is in flight
even though 5, 6 and 8 are done, and then jumps to 7 rather than 9, because 8 is
complete but not contiguous.

`userSucceedsButProduceToBrokerFails` is new - a path the audit found reachable
and untested. It asserts the consequence rather than the throw: the offset does
not advance, and the record is retried. No producer-callback-thread variant: that
is #261's, and it is unreachable here because the harness gives every test
one auto-completing MockProducer that calls back on the calling thread.

Each was mutation-checked rather than trusted for being green - breaking one
expected value (of(3,4,6)->of(3,4,5); p1 4,7->4,9; removing the injected produce
failure) reds all three modes. The `@Disabled` import goes with the annotations,
its last users.

`docs/test-hardening/dark-core-tests-measured-commit-sequences-2026-08-12.md` is
deleted in the same change. It was salvaged one commit ago to stop these
measurements dying with the plan that held them; they now live in the tests that
assert them, with the reasoning in comments. A prose copy of numbers an assertion
already pins is the drift this PR removed from `docs/todo-index.md`.

Core unit suite: 345 tests, 0 failures under -Pci, up 7 with 2 fewer skips. All
four repo gates pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ath it took

CI red on `processInKeyOrder[1]`, and the defect was in the test I had just
written, not in the library.

It asserted the exact SET of commits per partition. The CI runner is slower, and
there partition 0 read `[1, 3]` where three local runs read `[3]`. Both are
correct: `1` means "record 0 done, resume at 1", an intermediate commit that
lands when a commit tick falls between record 0 completing and 1 and 2
completing. On a fast machine the whole run 0-2 completes inside one tick and
only `3` is ever committed.

So the assertion was a statement about where the wall-clock commit ticks fell,
which is exactly what #260 established a test cannot do - it collapsed
PC's repeat commits inside `assertCommits` for that reason. I reproduced that
lesson in a different shape: not a repeat, an extra intermediate step on the way
to the same place. Three green local runs did not reveal it, and could not have.

Now asserted through `awaitFrontier`: the highest committed offset per partition
- where consumption would resume - which is the invariant, while the path to it
is not. `max([1, 3]) == 3`, so this specific failure cannot recur by
construction rather than by timing luck.

The assertion stays sharp. The frontier only moves when work completes
contiguously, so a partition that advanced past in-flight work still fails -
mutation-checked by asserting partition 1 reaches 9 rather than 7 at the
key-order checkpoint, which reds all three commit modes.

The first checkpoint keeps `assertCommitLists`: nothing has completed on
partition 0 there, so no intermediate value is possible and the exact-set form
is stable.

Core unit suite: 345 tests, 0 failures under -Pci, and processInKeyOrder green
3/3 consecutive runs. All four repo gates pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@astubbs astubbs left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

docs/inflight/pr-263-264-inactive-test-stack.md needs trimming

…me it

#263 is merged and GitHub retargeted this PR onto master, so the top of
the note was false where it mattered most: it still said #264 was stacked,
that #263 must merge first, and that `Check PR Dependencies` fails by
design. That check passes.

`docs/inflight/AGENTS.md` says what to do with the rest: when something closes,
do not rewrite it into a FIXED/DONE narrative - shrink the file to the open
follow-ups and rename it. The "Settled" section was exactly that wrong move, and
it duplicated the commit messages.

80 lines to 38, carrying the two things that are actually open: the undecided
LoadTest auto-run question, and the audit's known drift. Every surviving claim
re-checked against the tree and the API.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@astubbs astubbs changed the title test(offsets): assert the codecs OffsetEncodingTests was branching around, and clear the dead tests test: act on the inactive-test audit - the tests that did not run, assert or exist now do Aug 13, 2026
astubbs and others added 3 commits August 13, 2026 01:19
…correct the perf-lane comment

The new `asyncConsumeAndProcessAtVolume` runs automatically in the required
Performance Tests leg at ten times the gating volume, on a class listed in the
load-tightness flake family at 1/20 and undiagnosed. AGENTS.md says to separate
test-infra contention from a real concurrency bug before touching a deadline, so
that is what was done rather than guessing.

Given an uncontended broker, the case ran 5/5 green at 40,000, each in ~52s
against its derived 600s ceiling. The code is fine at this volume and is nowhere
near the deadline, so by that rule this family's failures are contention. The
rung stays automatic.

What the measurement could NOT clear is recorded at the site, because it is the
thing to reach for if this ever does flake: the performance lane does not give it
an uncontended broker. Failsafe declares no forkCount, so all four
@tag("performance") classes share one JVM and therefore the one static
BrokerIntegrationTest.kafkaContainer, with <parallel>methods</parallel>. The
gating integration lane already solves exactly this by forking
(-DforkCount=4 -DreuseForks=true); this lane never got that treatment.

Also corrects two falsehoods in the failsafe comment that sent readers wrong:

- It cited a `performance.yml` workflow on dedicated hardware. Neither exists.
  Performance tests run in maven.yml's leg on ubuntu-latest - a required check on
  every PR - and in pr-highcpu-fast-feedback.yml's highcpu lane.
- It told readers to override with `-Dgroups=performance`, which does nothing:
  the <groups> element is pinned to ${included.groups}, so the explicit pom value
  wins and the bare property is silently ignored. Same trap the repo already
  documents for -DforkCount vs -Dsurefire.forkCount. The working flag is
  -Dincluded.groups=performance.

Reactor test-compile clean; all four repo gates pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ity comment

The comment claimed "0, 1 and 2 are all key-1 on partition 0". They are not.
`primeFirstRecord` and `sendSecondRecord` both make **key-0**, so offsets 0 and 1
share key-0 - which is why 1 is blocked by 0, the thing this part of the test is
demonstrating. Offset 2 is key-1, and so completed independently rather than
being freed by 0.

The mechanism the comment describes was right and the assertion is unchanged;
the key naming was wrong, and it contradicted the assertion four lines above it
that says 1 is "blocked by 0 ... due to key order processing". Found by an
adversarial read of the surrounding evidence, not by a failing test - nothing
executes a comment.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… left behind

Two loose ends the compounding pass surfaced.

`docs/inflight/test-untracked-ci-flakes.md` still listed
`queuedMessagesNotProcessedOrCommittedIfSubmittedDuringShutdown` at 3/45 as an
open regression, with a whole section on why to start there. #260 fixed
it - its commit message names that test and that rate - and is on master. Per
`docs/inflight/AGENTS.md` the entry is removed rather than rewritten into a
FIXED narrative; the header now says which of the scan's three closed and that
no product change was needed, because the extra commit was correct behaviour and
the assertion was wrong.

The learning doc listed the remaining strict call sites as an unswept remainder.
They are now swept, and none is exposed - which sharpens the rule rather than
weakening it:

  the exact form is only unsafe where a partition can pass through a NON-GENESIS
  intermediate frontier that the expected value omits, which needs three or more
  records on one partition advancing the frontier in two steps between
  checkpoints.

The four `assertCommitLists` sites outside `processInKeyOrder` are all
two-records-per-partition, so partition 0 goes genesis-0 (trimmed) straight to
its frontier and partition 1's expected values are the successive frontiers
themselves. Every `awaitForCommitExact(int)` call site commits a single record.
`processInKeyOrder` was the only three-record shape - offsets 0, 1 and 2 with 2
completing before 0 - which is why it was the only one that failed. Relaxing the
others would have cost assertion strength for no defect.

Also carries the ce-compound output: the learning itself and its CONCEPTS.md
entries (commit frontier, tick-path assertion).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@astubbs astubbs left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

astubbs and others added 3 commits August 13, 2026 01:38
…ling deadline scaling

Three cleanups from a four-angle quality pass. No behaviour change: 345 tests,
0 failures.

`awaitForCommitExact(int partition, int offset)` is deleted. This PR replaced its
only five call sites - all in processInKeyOrder - with the frontier assertions,
which left a shared base-class method nothing in the tree calls. Worth being
explicit that this is not the same defect the method was written for: it verified
`sendOffsetsToTransaction` on the producer spy, so it only ever worked under
PERIODIC_TRANSACTIONAL_PRODUCER, and processInKeyOrder is parameterised across all
three commit modes - the old call was silently valid for one of them. Its javadoc
about tick placement was right and is not lost; that reasoning now lives in
docs/solutions/test-flakiness/assert-the-commit-frontier-not-the-tick-path.md.

Considered and rejected: rebuilding the frontier assertions on the existing
`hasCommittedToPartition(tp)` truth subject. That reads the mock CONSUMER's commit
history, and under PERIODIC_TRANSACTIONAL_PRODUCER commits go to the producer -
which is exactly why `getCommitHistory()` dispatches on commit mode. The two
existing helpers each cover one side of that split; neither spans it.

`TransactionAndCommitModeTest.timeoutFor` now calls `completionCeiling` instead of
hand-rolling the scaling. The hand-rolled form truncated, and worst precisely where
the recovered ladder is meant to be used: at 40 threads `GATING_CONCURRENCY /
threads` is 64/40 = 1 in integer division, so that rung got no scaling at all
against a true ratio of 1.6 - a 60s deadline where 96s was owed. `completionCeiling`
scales in Duration nanos, floors at the baseline (preserving "raising concurrency
never shortens it"), rejects a non-positive knob rather than flooring it, and is
unit-tested.

`awaitFrontier` calls are now in a consistent (partition 0, partition 1) order at
all four checkpoints; two of them had the pair reversed for no reason, which reads
as significant when it is not.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…e the review's four P1s

A seven-reviewer pass found four P1s in this PR. Two were reproduced by running
the tests, not by reading them, and the first is the one that matters.

`offsetsAreNeverCommittedForMessagesStillInFlightLong` asserted the exact commit
history, which is a claim about where the wall-clock commit tick fell. Measured:
it failed 3 of 10 runs, as [1, 3] where [3] was expected and [3, 4, 5, 6] where
[3, 4, 6] was, in two different commit modes. Both are correct PC behaviour -
releasing 4 and 5 together does not guarantee one advance, and completing 0 does
not guarantee 1 and 2 drain before the next tick.

This is exactly the defect this PR diagnoses, documents in
docs/solutions/test-flakiness/assert-the-commit-frontier-not-the-tick-path.md,
and fixes in processInKeyOrder - applied to one test and not to its sibling
twenty lines away. Every record here is on partition 0, so it takes the same
awaitFrontier treatment. My own verification could not have caught it: 3/3 green
locally, four green full-suite runs, two green CI runs. A 1-in-6 flake survives
all of that, which is the sentence the learning doc already contains.

Now 12/12 clean on the same full-class runs that failed 3 of 10.

Also from the review:

- processInKeyOrder point-checked `processedState.get(2)` where the worker
  thread writes it after waking; the control loop can turn twice first. Failed
  1 of 10 runs. Now awaited, matching what the same test already does for
  records 5 and 6.
- Two of the four recovered knobs were documented with commands that select
  ZERO tests and exit BUILD SUCCESS: both classes are @tag("performance"), the
  default excluded.groups contains performance, and exclusion beats inclusion -
  so `-Dincluded.groups=performance` alone selects nothing. Verified: Tests run: 0.
  Both now point at bin/performance-test.sh, which passes -Dexcluded.groups= too.
  The pom comment this PR added said "or -Dexcluded.groups=" and taught the same
  trap; it now says BOTH. The other two knobs were checked and are fine -
  TransactionAndCommitModeTest is @tag("transactions"), not excluded by default.
- redact() masked on the key only, so a credential inside a VALUE under an
  innocuous key printed verbatim to CI logs - a JDBC URL with ?password=, or a
  URL with userinfo. It now scans the value as well, and `passphrase` is a marker
  (this repo signs releases with maven-gpg-plugin, and "passphrase" is not
  "password"). NOT `pat`, which was suggested: it substring-matches
  java.library.path and would mask most of the dump. A test pins that.
- The perf-lane diagnosis was wrong and disproved at bytecode level: Surefire's
  JUnit Platform provider never reads failsafe's <parallel> element, and -Pci
  sets parallel-tests=false regardless. The lane is sequential in one fork, so
  the first suspects are heap accumulated under reuseForks, container start-up
  and the 60-minute cap - not broker contention between concurrent tests.
- Dropped the `assertCommits(of())` that raced partition 1's bootstrap commit;
  the awaited per-partition assertion below already covers it without racing.

Core unit suite: 347 tests, 0 failures under -Pci. All five repo gates pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…would have merged stale

The code-review pass left findings that were deliberately not folded into the
fixes: each is a change to shared machinery rather than to the work under review,
and burying them in a P1 commit would have hidden them. They are now tracked
where a future branch will find them.

`test-required-perf-lane-scope.md` - what belongs in the REQUIRED Performance
Tests leg. Records the settled part (the 40,000 rung stays automatic, on 5/5
uncontended green at ~52s against a 600s ceiling, and it then passed the real
lane) and the part that is not settled: `LoadTest extends DbTest`, whose static
initialiser starts a Postgres container that no test in that lane reads or
writes, and which is itself listed at 2/20 for "postgres container start under
contention". Also records that `-Dload.total` moves the untagged gating tests
too, which is a trap if that flag ever reaches a lane.

`test-inactive-test-review-followups.md` - the deferred code findings. Chiefly:
`awaitFrontier` should live in the shared test base, not private to one class.
The learning this work produced argues that #260's rule failed to
generalise because it sat somewhere you only read if you already held the helper
- and the fix for it was then put somewhere only one test class can reach. The
note carries the two blind alleys already checked (the deleted
`awaitForCommitExact(int,int)` was transactional-only; `hasCommittedToPartition`
reads the consumer, so neither spans the three commit modes), the holding-variant
fix for the frontier's negative checkpoints, and two `CompletionCeiling` items.

`pr-264-inactive-test-remediation.md` is deleted rather than carried. Per
`docs/inflight/AGENTS.md` a `pr-` note is context about an OPEN pr, and work a PR
resolves is deleted in that PR - so a note added by #264 describing
#264 lands on master describing a closed one, which is the exact failure
that file warns about. Its two surviving items moved into the notes above: the
perf-lane question and the audit's known drift.

One P3 fixed rather than filed: the `timeoutFor` comment cited "a 60s deadline
where 96s was owed" when `defaultTimeout` is 30s, so the real figures are 30s and
48s. The ratio argument was right; the absolute numbers were not.

Reactor test-compile clean; all five repo gates pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@astubbs astubbs left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@astubbs

astubbs commented Aug 13, 2026

Copy link
Copy Markdown
Owner Author

@claude please review this PR's head 970c5219.

Two workflow_dispatch runs of claude-code-review-dispatch.yml have now concluded success without posting a comment (the latest: run 31661054863, 1m09s, log line "The reviewer ran and concluded successfully"). The newest claude[bot] comment on this PR is against cac1599b, so everything since then is unreviewed - while claude-review reads green, because the gate asks only whether a finished review exists on the PR, not whether it covers the current head (docs/inflight/parked-strict-review-gate-freshness.md). Trying the comment trigger instead, since that path worked at cac1599b.

Where to look hardest. A seven-reviewer pass already covered the older commits; the four newest are what needs scrutiny:

  1. ParallelEoSStreamProcessorTest - the frontier rewrite. Two tests now assert the committed-offset frontier (highest offset per partition, via a private awaitFrontier) instead of the exact commit history, because the exact form asserted where the wall-clock commit tick fell - it failed 3/10 runs as [1, 3] vs [3] and [3, 4, 5, 6] vs [3, 4, 6]. Does the rewrite still catch what it must? Specifically: would processInKeyOrder still fail if a partition committed past in-flight work? An earlier reviewer argued the negative checkpoints now sample an instant where the old form constrained continuously, so a spurious commit landing between two checkpoints is invisible to max. I judged that bounded and deferred the holding-variant fix to docs/inflight/test-inactive-test-review-followups.md - tell me if that call was wrong.

  2. AmbientProbeExtension.redact. It now scans property values for embedded credentials (password=, URL userinfo) as well as key names, because key-only matching missed a credential inside a value under an innocuous key. Check it does not over-mask: the dump's diagnostic value is completeness, and I deliberately rejected pat as a key marker because it substring-matches java.library.path. Also worth checking whether the value regex can false-positive on ordinary properties.

  3. Two javadoc commands re-pointed at bin/performance-test.sh. -Dincluded.groups=performance alone selects zero tests (exclusion beats inclusion, and the default excluded.groups already contains performance), so the documented invocations exited BUILD SUCCESS having run nothing. Verify the replacements actually select the intended test, and that I did not miss a third site.

  4. LoadTest javadoc. The previous claim that the perf lane runs <parallel>methods</parallel> was wrong - Surefire's JUnit Platform provider never reads that element and -Pci disables parallelism regardless. It now says the lane is sequential in one fork. Please sanity-check that correction rather than trusting it.

Please run the tests yourself rather than trusting my numbers - the whole point of finding 1 is that green local runs are not evidence for a timing-sensitive assertion. bin/ci-unit-test.sh covers the changed unit tests.

@claude

claude Bot commented Aug 13, 2026 •

Copy link
Copy Markdown

Claude finished @astubbs's task in 7m 7s —— View job


Claude's review of PR #264 head 970c5219

  • Confirm HEAD matches 970c5219, scope diff to the five newest commits since cac1599b (1887362, 88b0b1e, 8c01831, be8194d, 970c521)
  • Item 1: ParallelEoSStreamProcessorTest frontier rewrite — traced awaitFrontier, offsetsAreNeverCommittedForMessagesStillInFlightLong, processInKeyOrder, and the follow-up doc
  • Item 2: AmbientProbeExtension.redact — read the key/value masking logic and its tests
  • Item 3: verified the bin/performance-test.sh javadoc re-points and searched the whole tree for a missed third site
  • Item 4: sanity-checked the LoadTest/failsafe <parallel> javadoc correction against pom.xml and junit-platform.properties
  • Ran CompletionCeilingTest myself — 4/4 green
  • ParallelEoSStreamProcessorTest / AmbientProbeExtensionTest still running in the background
  • Post findings

@astubbs

astubbs commented Aug 13, 2026

Copy link
Copy Markdown
Owner Author

@claude please review head 970c5219 again - read only, do not run any tests this time.

The previous run (job 31661308740) spent 68 turns / 7m07s and ended having ticked the four analysis items but with "Post findings" still unticked - it backgrounded ParallelEoSStreamProcessorTest and AmbientProbeExtensionTest and never got back to synthesising. It reported subtype: success, so nothing crashed; the budget just went into test execution. So:

Do not run any test suite, any ./mvnw, or bin/ci-unit-test.sh. Spend the whole budget reading and reasoning. The test evidence is already established and you can take it as given:

  • Core unit suite on this head: 347 tests, 0 failures, 8 skipped under -Pci.
  • The flake that motivated the frontier rewrite was reproduced at 3/10 before the fix and is 12/12 clean after, on full-class runs.
  • All five repo gates pass (todo-index --check, copyright, docs-data, quarantine registry, issue-refs).
  • CI on this head is green: 28 checks pass, 0 fail.

Write your findings into your own tracking comment (update_claude_comment) - on this path you were not granted gh pr comment, so that comment IS the deliverable. Tick every box or use plain bullets; an unticked - [ ] is read as "stopped partway".

What I want judged, by reading the diff and the surrounding code only:

  1. Does the frontier rewrite still catch a partition committing past in-flight work? awaitFrontier asserts the max committed offset per partition. An earlier reviewer argued the "must not advance" checkpoints now sample an instant where the previous exact-history form constrained continuously, so a spurious commit landing between two checkpoints would be invisible to max. I judged that bounded and deferred a holding-variant fix to docs/inflight/test-inactive-test-review-followups.md. Was that the wrong call?

  2. Can AmbientProbeExtension.redact over-mask? It now scans values (password=, URL userinfo) as well as key names. Can the value regex false-positive on an ordinary property and blank something diagnostic? I rejected pat as a key marker because it substring-matches java.library.path - are any of the markers I did add (pwd, passphrase, privatekey) similarly dangerous?

  3. Did I miss a site where -Dincluded.groups=performance is documented without -Dexcluded.groups=? Two javadocs were re-pointed at bin/performance-test.sh; TransactionAndCommitModeTest and LoadTest were judged already-correct because their tags are not in the default exclusion. Check that reasoning.

  4. Is the LoadTest javadoc correction sound - that the perf lane runs sequentially in one fork because -Pci sets parallel-tests=false and Surefire's JUnit Platform provider ignores failsafe's <parallel> element?

If you find nothing blocking, say so plainly and tick the boxes - a clean read is a useful result.

@claude

claude Bot commented Aug 13, 2026 •

Copy link
Copy Markdown

Claude finished @astubbs's task in 5m 22s —— View job


Claude's review of PR #264 head 970c5219 (read-only re-run)

  • Confirm HEAD matches 970c5219
  • Q1: frontier rewrite — can a spurious commit between checkpoints be invisible to max?
  • Q2: AmbientProbeExtension.redact — can the value regex or new key markers over-mask?
  • Q3: any site documenting -Dincluded.groups=performance without exclusion, missed?
  • Q4: is the "perf lane runs sequentially in one fork" javadoc correction sound?
  • Post findings

No test suite, ./mvnw, or bin/ci-unit-test.sh was run this pass, per instructions — this is a read of the diff and surrounding source only.

Q1 — the gap is real, and you already found and documented it; deferring was the right call

Traced awaitFrontier/highestCommitFor in ParallelEoSStreamProcessorTest.java against every checkpoint in offsetsAreNeverCommittedForMessagesStillInFlightLong and processInKeyOrder. The gap the earlier reviewer flagged is real: await().untilAsserted returns on the first passing poll, and since highestCommitFor is a monotonic max, a bug that commits a partition's frontier past in-flight work would only be caught if it produces a value different from what the checkpoint expects. If the premature commit happens to land on the same numeric value the test would reach anyway once the in-flight record legitimately completes, the checkpoint can't distinguish "reached 7 because 4-6 finished" from "reached 7 early, while 4 was still in flight." This is exactly what docs/inflight/test-inactive-test-review-followups.md's "The frontier's negative checkpoints sample rather than hold" section already states, with the same partition-1/record-4 example and a concrete fix (awaitFrontierAndHold, holding the value for verificationWaitDelay).

What partially bounds it in practice, and is worth being explicit about since it's not in the deferred doc: several checkpoints in processInKeyOrder still use assertCommitLists/assertCommits, which are strict-equality checks against the whole commit history (verified: assertCommitLists at AbstractParallelEoSStreamProcessorTestBase.java:453 delegates to ktu.assertCommitLists, not a contains/max-based helper) — e.g. assertCommitLists(of(of(), of(4))) right before unlocking record 0 pins partition 0 at empty. So a premature over-commit on partition 0 in that specific window would still be caught. The genuinely open window is narrower than "any negative checkpoint" — it's the checkpoints that went from an explicit assertCommits(of()) (continuous) to no negative assertion at all, per the "No 'nothing is committed yet' check here" comment, combined with any awaitFrontier whose target value coincides with what a premature-but-eventually-correct commit would also reach.

Given: (a) the gap is scoped and already root-caused rather than hand-waved, (b) a concrete fix is designed and ready to implement, (c) it touches shared test-base machinery (awaitFrontier/highestCommitFor are flagged in the same doc as belonging in AbstractParallelEoSStreamProcessorTestBase, not staying private to this one class) which is a legitimate reason to not fold it into an already-large PR, and (d) the measured 3/10→12/12 flake fix is what this rewrite was actually for and remains intact — deferring was not the wrong call. I'd call it medium-priority follow-up rather than low, though: this is precisely the invariant processInKeyOrder exists to guard (key-order/commit-frontier correctness), so of all the deferred items in that doc, this is the one I'd promote first.

Q2 — no over-masking found; the markers and regex are conservative

Read redact/SECRET_KEY_MARKERS/SECRET_IN_VALUE against realistic JVM/Maven/Surefire system properties (java.*, sun.*, user.*, os.*, surefire.*, maven.*, classpath strings, etc.) and against the test cases already in AmbientProbeExtensionTest.java:

  • Key markers pwd, passphrase, privatekey: none of them are substrings of any standard JDK/Maven/Surefire/Failsafe/Testcontainers system property name I could find (java.library.path, sun.java.command, sun.os.patch.level, surefire.test.class.path, etc. — none contain pwd, passphrase, or privatekey). gpg.passphrase is explicitly tested and correctly masked (it's a real Maven release-plugin flag, and the test comment calls out that it isn't confused with password). I couldn't construct a plausible innocuous property that any of these three would catch — they look properly scoped, same spirit as the pat/java.library.path rejection you already made.
  • Value regex SECRET_IN_VALUE: the key=value/key:value alternative requires the marker word immediately (modulo whitespace) followed by = or : then a non-whitespace char — secretsanta.jar, classpath entries like .../secret-utils.jar:/other.jar, or path segments don't match because the marker isn't directly adjacent to =/:. The URL-userinfo alternative requires ://user:pass@, which ordinary values (Kafka bootstrap strings like PLAINTEXT://broker:9092, classpaths, plain URLs without userinfo) don't contain. I couldn't find a realistic false-positive case; the existing environmentDumpDoesNotOverMaskOrdinaryProperties test (asserting java.library.path survives intact) covers the case you were specifically worried about.
  • Minor, non-blocking observation: there's no test exercising the pwd/privatekey key markers specifically (only password is covered in environmentDumpMasksValuesOfCredentialLookingKeys) — not a correctness issue, just a coverage gap if you want belt-and-suspenders.

Q3 — reasoning checks out; no missed site within this PR's scope

Grepped the whole tree for included.groups=performance / excluded.groups. Three places needed the "include alone selects nothing" caveat and all three now have it correctly:

  • pom.xml's failsafe <parallel> config comment (fixed in be8194d) — also correctly retired the stale -Dgroups=performance suggestion, and added the "why not -Dgroups=performance" trap explanation (verified: <groups>${included.groups}</groups> is pinned, so a bare -Dgroups= is silently ignored, matching the comment's claim).
  • MultiInstanceHighVolumeTest.java and VeryLargeMessageVolumeTest.java javadocs (fixed earlier, refined in 689b7b5).
  • LoadTest.java's new asyncConsumeAndProcessAtVolume javadoc was written correctly from the start (never had the wrong claim to begin with).

TransactionAndCommitModeTest is untagged entirely (confirmed in the diff — no @Tag, reached only via -Dtransactions.concurrency), so there's no group-inclusion claim for it to get wrong; "already correct" for that one just means no tag mechanism applies, not that a tag-related doc was checked and found fine. That distinction is worth having explicit for your own records, but it doesn't change the conclusion.

The only remaining tree-wide hits for -Dincluded.groups=performance without a paired -Dexcluded.groups= are in docs/plans/2026-07-29-002-fix-drain-zombie-spin-and-uber-experiment-plan.md (lines 93, 220) — a dated historical plan doc, not touched by this PR and outside its diff, so not a "missed site" in the PR under review, just a pre-existing loose end elsewhere in the repo if it ever matters.

Q4 — sound

Verified independently: parallel-consumer-core/src/test/resources/junit-platform.properties (the only junit-platform.properties in the tree, added to both unit and integration test resources via pom.xml's add-test-resource binding at generate-test-resources) sets junit.jupiter.execution.parallel.enabled=${parallel-tests}, and the -Pci profile sets parallel-tests=false (pom.xml:210). That property, not failsafe's <parallel>methods</parallel> XML element, is what actually governs JUnit 5 Jupiter parallelism — Surefire/Failsafe's <parallel> element is a JUnit4/TestNG-provider concept and isn't read by the JUnit Platform provider (confirmed by the absence of any binding between it and the Jupiter engine's own parallel config in this pom). Additionally, the failsafe plugin block has no <forkCount> binding at all (only surefire's does, at pom.xml:876), and bin/performance-test.sh doesn't pass -DforkCount either, so it runs at failsafe's default forkCount of 1 — consistent with the javadoc's claim that all four @Tag("performance") classes share one fork/one heap. The correction is accurate on both halves: sequential (via parallel-tests=false), and in one fork (via failsafe's unoverridden default).

Summary

Nothing blocking found. Q3 and Q4 check out cleanly with no gaps. Q2 has no over-masking risk I could find. Q1's deferred gap is real and already correctly diagnosed and scoped in your own follow-up doc — I'd endorse the deferral but suggest treating it as the top item in that doc rather than an equal-weight one, given it's the exact invariant class this rewrite exists to protect.
· branch test/inactive-test-remediation

@astubbs astubbs changed the title test: act on the inactive-test audit - the tests that did not run, assert or exist now do test(core): act on the inactive-test audit - the tests that did not run, assert or exist now do Aug 13, 2026
@astubbs
astubbs merged commit 3fda0db into master Aug 13, 2026
38 checks passed
@astubbs
astubbs deleted the test/inactive-test-remediation branch August 13, 2026 03:20
astubbs added a commit that referenced this pull request Aug 13, 2026
…d-waits

Brings in #264 (now merged), which was this PR's declared dependency, plus
#277, #260 and #263.

One conflict, in docs/todo-index.md - a generated file. Master's bin/todo-index.sh
changed the header format (the marker count moved out of the prose) while this
branch still carried the old shape, so both sides had edited the same generated
line. Resolved by regenerating from the merged tree rather than picking a side:
84 markers, and `bin/todo-index.sh --check` reports it current.

Master did not touch BlockedThreadAsserter or junit-platform.properties in these
four commits, so this PR's two central changes had no semantic collision to
resolve. Verified after merging: junit-platform.properties still deleted, core's
pom still carries the surefire/failsafe configurationParameters, and the asserter
rewrite plus its negative-control test are intact.

Local verification: core 354 tests and vertx 18, 0 failures, 0 errors.
bin/check-quarantine-registry.sh and bin/check-copyright-headers.sh both clean.
astubbs added a commit that referenced this pull request Aug 14, 2026
…and stop two smaller lies next to it

A sweep of the other pollDelay sites, prompted by the produceTimeout fix. The two
in CloseAndOpenOffsetTest are not the same defect as each other, and only one of
them is the same class.

correctOffsetVerySimple IS an instance, of the vacuity variety. It asserted that
a freshly opened PC reads nothing back after a flat 1s wait, with nothing
establishing that the PC had joined the group - so "nothing was read" was equally
true of a consumer that never finished joining. Control arm, pointing that PC at
a decoy topic: the original assertion passes, the anchored one fails at the
assignment await.

It now waits on PartitionStateManager#getPartitionState being non-null - a
ConcurrentHashMap, so unlike Consumer#assignment it is safe to read from the test
thread while the poll thread runs - and then produces one record AFTER the
absence window that must be read. Assignment proves it joined; the trailing
record proves its poller reached the topic. Same rule as
TransactionalPartialResultSetIT#proveVerifierIsActuallyReading: prove the
detector works before trusting what it did not detect. readByThree becomes a
ConcurrentLinkedQueue, since the test thread now reads it while a worker writes.

largeNumberOfMessagesSmallOffsetBitmap is NOT an instance - its assertion
retries, so a slow start costs time, not correctness. Two smaller things were
still true of it:

- atLeast(500ms) behind pollDelay(1000ms) can never fire. Measured: raising the
  atLeast to 1500ms reports the condition "evaluated in 1 seconds 6 milliseconds",
  so at 500ms it was dead. Removed.
- The trailing hasSize was commented "double check after closing" while sitting
  inside the try-with-resources, so it ran before close. Moving it out does not
  earn the claim: produce an extra record after the await and flush it to the
  broker before close, and PC never delivers it - it stops fetching at close - so
  both positions still pass. The comment now says what the assertion is, a
  restatement, rather than the assertion being relocated on a theory the control
  refuted.

Also cross-links the frontier/tick-path rule from #264, and names this
change's deliberately-unclosed residual as an instance of it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
astubbs added a commit that referenced this pull request Aug 14, 2026
…298)

Two merged PRs, #264 and #277, carry no LGTM in any form - no
review, no comment. The requirement is that the owner reviews everything that
goes in, and the gap was not a lapse of intent but of visibility: "have I read
this one myself yet?" is a thing to carry across a dozen open PRs, and carrying
it does not work.

So it becomes a check with its own name. `bin/check-human-lgtm.sh` asserts one
thing: the owner has left a REVIEW whose body contains "lgtm", any case,
anywhere in the body. The reviews endpoint is the rule rather than an
implementation detail - "lgtm" typed into the ordinary comment box is not the
deliberate act being asked for - and the endpoint gives that distinction for
free.

The matching rule was settled by looking rather than by taste. All 50 owner
LGTMs this repo has received, across 38 PRs from #63 to #292, are
COMMENTED reviews; 49 are lower-case `lgtm` and one, on #84, is `Lgtm`.
Four carry a trailing clause, one of them ending in a question mark. A
case-sensitive or whole-word rule would have gone red on real history, so both
of those real spellings are pinned as cases.

NOT HEAD-SENSITIVE, deliberately: an LGTM on any commit counts for the whole PR,
permanently, because the owner only stamps a PR once it is near merge. That is
why review STATE is not consulted at all - the master ruleset sets
dismiss_stale_reviews_on_push, so reading state would silently un-stamp a PR the
owner had already stamped.

A SEPARATE JOB, NOT A SECOND STEP IN claude-review, and that is the substance of
this change rather than a packaging choice. Two checks say WHICH half is missing
straight from the checks list - "claude-review" red means no automated review,
"review: human LGTM" red means the owner has not read it yet - and one combined
check is red either way, which is exactly the question the human half exists to
answer. It also leaves claude-review byte-identical to master: no rename, so no
transitional duplicate job and no ordered ruleset swap, and a required check
matched by name cannot be left pointing at nothing. Making the new context
required is additive, once it has merged and is reporting.

NO BOT EXEMPTION, unlike the automated half. A Dependabot PR does not need an
AUTOMATED review, but it is still a change going in. Having no guard also means
there is no job to skip - and a skipped job satisfies a required check, so a
guard keyed on github.event.sender would have let a human PR synchronized by a
bot go green having asserted nothing.

The checker is 15 lines. An earlier revision was 593, with 855 lines of
self-test, parsing code fences, blockquotes, negation forms, glued repeats, CRLF
and typographic apostrophes - defences against an attacker who is also the only
person the check protects. Filtering the reviews with jq on .user.login before
any text is read removed both the attack and the unguessable per-run marker
token it needed, since a stranger's body can no longer be attributed to the
owner.

Verified against real data, not only fixtures: #206 reads LGTM-present,
#298 and #299 read absent. The self-test carries a negative
control proving the check can fail at all.
astubbs added a commit that referenced this pull request Aug 17, 2026
…ponse-timeout

61 commits of master, including the tree-wide package rename that this branch had
already run for itself. Both sides renaming independently is what made the merge
look enormous: git paired only some of the moves, so the same file arrived as a
rename/delete plus an add/add rather than as one rename/rename. 45 conflicts over
34 files, none of them a real disagreement about behaviour.

The add/add pairs were re-merged by hand as proper three-way merges, using the
pre-rename io.confluent blob at the merge base as the common ancestor - which is
the ancestor git could not find on its own once master rewrote several of these
files after moving them (#206 dropped MockConsumerTest and friends below
the rename-detection threshold). Every one of those eight then resolved to
master's content exactly: this branch had contributed nothing to them but the
rename.

Resolutions worth knowing about:

- The eight logback-test.xml files were both sides deleting the same dead csid
  logger lines - master in #289, this branch in 76dc3ed mirroring it.
  Master's copy taken wholesale.
- docs/inflight/ci-review-agent.md: master's rewrite taken wholesale. Every entry
  this branch still carried is now either fixed (the SIGPIPE gate - story kept in
  docs/solutions/workflow-issues/a-check-that-reports-success-without-having-run.md)
  or stale (the actionlint and bin/todo-index.sh grants are both in the allowlists
  on master). The file's own contract is that it holds open gaps only.
- docs/inflight/test-load-tightness-flakes.md: both sides kept. Master reclassified
  commitTimeout[1] out of the family for an unforceable trigger; this branch's entry
  is commitTimeout[2], about the assertion rather than the trigger. Neither
  supersedes the other, and the section now says so instead of leaving a reader to
  find two verdicts on the same test name. Its ConsumerOffsetCommitter:96 citation
  is re-pointed at a greppable anchor, per the rule that arrived in #283.
- JavaEnvTest, StringTestUtils, junit-platform.properties,
  SampleTestingFailsafePluginInclusionCore and the two .idea run configurations:
  master deleted them in #264 and #265, this branch had only renamed
  them. Deletions accepted; nothing in the tree still refers to them.
- bin/rename-packages.sh: master's copy. This branch took the tooling from an
  earlier state of it and never modified it.
- The README summary paragraph: master's, which is frozen against the rename script
  precisely because it has to name the namespace a reader is moving off.

What this branch contributes on top of master is unchanged and now stands at nine
files: the three core classes, the two new tests, and four documents.

Verified: full unit suite, and bin/check-copyright-headers.sh,
bin/check-issue-refs.sh, bin/todo-index.sh --check, bin/check-action-versions.sh,
bin/check-docs-data.sh, bin/check-quarantine-registry.sh,
bin/check-quarantine-owners.sh, bin/check-shell-sigpipe.sh,
bin/check-cve-exclusions.sh all green locally.
astubbs added a commit that referenced this pull request Sep 1, 2026
…owners

THE NOTE HAD FALLEN BEHIND

`pr-offset-encoding-policy.md` still described the state three rounds of work ago.
Added what merge prep turned up and what no gate caught: the falsified
`docs/features/` entry, the javadoc the merge dropped, two dangling citations to a
class deleted in #267, and the SpotBugs overload finding. Also records what
was harvested from the stood-down `recut/207-offset-policy-bypass` and what was
deliberately not.

THE JSTREAM FLAKE IS NOT UNDIAGNOSED - #116 OWNS IT

Recorded as UNDIAGNOSED when it was carried across. Chasing it found #116,
"a result stream that ends before the results arrive", whose own description says
eight tests "passed ONLY because the stream quit early - they encoded the defect".
`testConsumeAndProduce` and `testFlatMapProduce` are two of them, and they are the
two seen failing empty. So the sighting is not test infrastructure at all: it is
that product defect observed racing the other way, which explains both why the two
failed together and why the class passes in isolation.

Entry now carries the mechanism and says to delete it when #116 lands rather
than diagnose or quarantine it separately. Posted the sighting on #116 too,
since it is evidence for a claim that PR currently only asserts.

A SECOND, DIFFERENT `processInKeyOrder` FLAKE

Hit while running the full core suite with CI running on the same box. Recorded
because it is NOT the `processInKeyOrder` flake
`docs/solutions/test-flakiness/assert-the-commit-frontier-not-the-tick-path.md`
already covers - that one is a 30s ConditionTimeoutException in `assertCommitLists`
and its fix merged with #264. This one fails in ~0.6s, before any commit
assertion: the test's own `[sanity check input data]` precondition finds `polled`
empty, because `awaitForOneLoopCycle()` is a fixed number of control cycles
standing in for "the consumer has polled its records".

Control-armed rather than assumed, which is the only reason it is filed as
contention: green 559/0 on a fresh worktree with the box idle at both this branch's
tip AND the commit before it, 2 failures twice with the box loaded, and green 68/68
for the class alone under that same load. The failing parameters differ between
runs, which rules out a deterministic break from this branch - #207 touches
offset decoding and nothing that test exercises.

Diagnosed from the assertion, not demonstrated. The entry says so and defers to the
ledger's classify-before-touching rule.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01228AtRiHyTzeH7SjcXzgNj
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant