Skip to content

feat(chaos): Chaos Pain Suite - calibrated, portable bug-detector pack (finds the drain-zombie on master blind) - #83

Merged
astubbs merged 56 commits into
masterfrom
feats/chaos-pain-suite
Jul 31, 2026
Merged

astubbs merged 56 commits into
masterfrom
feats/chaos-pain-suite

Conversation

@astubbs

@astubbs astubbs commented Jul 30, 2026 •

Copy link
Copy Markdown
Owner

depends on #75

A portable bug-detector pack: a seeded, calibrated chaos suite that hunts PC's "alive but not progressing" bug class on purpose - excluded from every gating suite, runnable on demand against any branch, and able to probe any fix PR: run it at a commit before the fix (RED, with the violation naming the mechanism) and at the fix (GREEN).

Lands independently of the fix PRs - deliberately early in the merge queue so every subsequent PR can use it.

What

Calibration - the suite is a measured instrument, not decoration

Test-the-test, executed against the real historical bug (no synthetic fault injection - the defect arm is simply a pre-fix commit):

Composition Verdict Peak rebalance dwell
Pre-drain-fix defect composition 🔴 3/3 RED - ZOMBIE_MEMBER/REBALANCE_BLOCKED 15.6-15.9s
All-fixes composition ✅ 3/3 GREEN 4.5-8.9s
This branch's own base (master) 🔴 RED - same probe 15.6s

NB: the 3+3 table predates the deterministic-scheduler rework (a52fd9e). The master-arm RED signature was re-confirmed on the reworked scheduler (seed 424242, same ZOMBIE_MEMBER/REBALANCE_BLOCKED, peak dwell 15.6s, different realized schedule - the detector is workload-robust, not schedule-lucky); the all-fixes GREEN arm should be re-certified on the #80 composition.

Class 2 probe calibration (added after): healthy arm 2/2 GREEN with peak lag stagnation ~39s vs the 150s bound (~4x margin); its first run fired at 151s on a healthy arm - a real measurement of legitimate redelivery chaining, fixed by calibrating the workload (heavy dwell 90s→45s), not by loosening the probe. RED calibration of the Class 2 probe continued in the W4 scenario family (#85/#87).

Yes: the suite reds on master today, on first contact - that is the point. Master carries the drain-zombie bug (fixed on PR #80); the detector found it blind. It gates nothing, so this PR's own CI is unaffected (the known RED is quarantined under #80, not hidden).

The 15s threshold is empirical, not guessed: identical seeded schedule run on defect and fixed arms, peaks measured (20.1s vs 6.7s), bound set in the gap - arithmetic recorded in the constant's javadoc.

Usage patterns

  • Probe a fix PR: on the fix PR's branch (merge master in first if it predates the suite landing), run -Dincluded.groups=chaos -Dexcluded.groups= at a commit before the fix and at the fix - watch RED→GREEN. The empty exclusion deliberately includes @Quarantined scenarios, so the known-RED detector still fires locally.
  • Replay a failure: every run logs its seed and the full replay command; -Dchaos.seed=N reproduces the schedule.
  • CI: chaos-pain.yml - on-demand dispatch (seed/reps) + per same-repo PR commit, non-gating.

Known coverage + next

Covers Class 1 stalls (protocol-visible rebalance freezes) with a calibrated RED trigger, plus the Class 2 probe (per-partition lag stagnation, protocol-invisible stalls) armed and GREEN-calibrated. Phase 2 landed on the stack: the W4 revoke-under-work scenario (#85) and its cooperative-sticky variant (#87, PC's first cooperative-mode exercise); later ideas (per-cause duplicate-ledger attribution, EoS variants, ambient probe #86) rostered in docs/inflight.md. Design doc: branch docs/chaos-pain-suite-design.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VbtaCN1Re14pJ99VFW4R18

Checklist

  • Changelog entry added (CHANGELOG.adoc, under == Unreleased) - Chaos Pain Suite entry (6f18e8d)
  • Docs updated - AGENTS.md (chaos suite run/replay section, quarantine + in-thread review policies), docs/inflight.md roster, docs/QUARANTINED_TESTS.md registry
  • Tests added/updated - the suite itself, plus gating fast tests (ChaosConductorPlanIT draw-path determinism, ProgressProbeLedgerIT boundary math, quarantine contract/script tests)
  • Title & body reflect the final content of this PR
  • Self-hosted runner / security implications considered - chaos-pain.yml pull_request trigger is same-repo-guarded (fork code never reaches the runner); workflow_dispatch inputs pass through env: (injection-hardened per the auto-review)

astubbs and others added 21 commits July 29, 2026 16:55
…same-repo only)

Optional, non-gating fast feedback that runs unit, integration and performance as parallel
matrix jobs on a self-hosted many-core runner (label `highcpu`), guarded to same-repo PRs so
fork code never executes on it. The GitHub-hosted gate in maven.yml stays the required check.

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

# Conflicts:
#	.github/actionlint.yaml
…-only

The high-CPU self-hosted matrix now runs unit + integration + performance + mutation as parallel
jobs (a strict superset of the mac runner, which is offline indefinitely). The mac workflow is
switched to workflow_dispatch-only so it stops queuing dead jobs on every PR.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
failingHttpCall drove an HTTP call at a dotless bogus hostname ("xxxxxxxxx") and asserted the failure
was a DNS *resolution* error ("failed resolve"). That only holds where the name fails to resolve - on any
network with a local resolver + search domain (e.g. a Pi-hole LAN) the name resolves and the failure mode
becomes "connection refused", so the test fails there while passing on GitHub's public DNS.

Point the bad request at a closed local port (127.0.0.1:1) instead: an immediate, deterministic
"connection refused" on every environment, no DNS lookup at all (and faster than one). Keep the real
failed==true check; assert the deterministic "connection refused" message. Found bringing up the
self-hosted high-CPU runner.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
…with failingHttpCall)

The failingHttpCall fix (127.0.0.1:1 -> connection refused) also flipped this sibling test through the shared getBadRequest() helper, so its assertion is updated to match. Caught by ce-review.

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
Load was ~18/32 with 34GB free - the box is I/O-bound (cold cache), not CPU-bound - so use all the cores.

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
…ateCommittedOffsetIT

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
…epo guard (ce-review P2)

The if: guard lives in the PR-head file, so the real RCE backstop is the repo Actions setting "require approval for all outside collaborators". Documented in the workflow header + referenced SELF_HOSTED_RUNNER.md.

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
Unit forkCount 1C->2C, Integration 8->16 (probe the oversubscription ceiling). Mutation PIT threads 2->16 (CPU-bound, stays in the matrix). Performance split into its own job that needs the matrix, so the throughput benchmark measures on a quiet box (solo 1m54 vs 7m18 when it shares the box).

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
…formance

Doubling was flat (unit 2C=1C) to worse (integration 16 slower than 8), so back to the knee. Performance returns to the concurrent matrix - it is a correctness gate here; noisy timing is fine and isolation wrecked total wall-clock (it queued behind a 17-min mutation). Mutation keeps threads=16. Accurate benchmarking -> separate on-demand run.

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
Unit/Integration now also enable JUnit method-parallelism (-Dparallel-tests=true) on top of forking, forks reduced so forks x threads ~= cores - tests whether thread-parallelism is still flaky after recent fixes (revert to fork-only if red). ci-mutation-test.sh: on a PR (GITHUB_BASE_REF) mutate ONLY changed core classes, skip if none - the full internal.* sweep has never completed. Full sweep still runs for push/nightly (no base ref).

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
…eads finding

fork×threads (parallel-tests=true) was safe (threading no longer races - unit green; integration red was the known flaky PartitionStateCommittedOffsetIT) but no faster than fork-only, so back to 1C/8. PIT: grep no-match under set -euo pipefail made the changed-class skip exit non-zero (0m19 red); wrap grep with || true so it exits 0. Recorded the thread-parallelism-vs-forking finding in inflight next to the shelved Step-2 question.

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
…bserve a green board

TEMPORARY - not a fix. Disables the known-flaky PartitionStateCommittedOffsetIT.committedOffsetRemoved (awaitility timeout, in inflight, fails on GitHub-hosted too) purely to see a fully-green highcpu run. Revert and harden the test properly.

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
Now that ci-mutation-test.sh scopes PIT to changed classes on PRs (GITHUB_BASE_REF), it is fast enough for the 2-core hosted runner - so mutation runs on GitHub-hosted as well, not just the self-hosted box. Non-gating (continue-on-error). fetch-depth: 0 so the changed-class diff resolves.

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
…already passed

Each GitHub-hosted test job, before running its slow 2-core suite, polls whether the self-hosted highcpu equivalent for the same commit already PASSED (ci-concede-check.sh). If so it skips and goes green; the hosted job stays the required gate but finishes faster when grumpy wins. Never depends on the self-hosted runner: offline/queued/slow/failed -> run the tests normally. Bounded wait, continue-on-error so a check bug can never fail the gate. Caveat documented: conceding trusts the self-hosted env (env-specific failures could be missed).

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
… the green-board experiment)

Reverts the temporary experiment disable. The test is still the known flaky awaitility timeout (tracked in inflight) - harden it (adaptive await / underlying timing) rather than leave it disabled.

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

Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
The check name is "<workflow> / <job>", and both halves carried "High-CPU"
plus verbose filler ("Build & Test - ...", "self-hosted, optional"), pushing
past the PR merge-box truncation width.

- workflow name: "PR High-CPU Fast Feedback" -> "highcpu"
- job name: "Build & Test - <suite> (high-CPU self-hosted, optional)"
           -> "<suite> (optional)"  (keeps the non-gating signal)

Result: "highcpu / Unit (optional)", "highcpu / Integration (optional)", etc.
- longest ~35 chars, well under the cutoff.

Kept the concede matcher in sync (it resolves the highcpu run/jobs by name):
bin/ci-concede-check.sh WORKFLOW default -> "highcpu", JOB_PREFIX -> "${SUITE}"
(the job is now named "<suite> (optional)", so a suite-name prefix still
uniquely matches). Added a keep-in-sync comment on the job. Updated the
SELF_HOSTED_RUNNER.md reference.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012ytagqk6daL4uTtbebQNNv
… behind Mutation's slow cancel

A single workflow-level concurrency group meant every new push's jobs waited
for the ENTIRE previous run to complete before starting. cancel-in-progress
signalled the old run immediately, but its Mutation (PIT) maven/JVM tree
rides out the runner's full cancellation grace (~5 min) before force-kill -
observed on PR #80: push at 22:41:05, old Mutation force-killed 22:46:06,
all four new jobs started 22:46:09. Head-of-line blocking on the one job
nobody needs fast feedback from.

Job-level per-suite groups (highcpu-<suite>-<branch>) mean a new push
supersedes each suite independently: Unit/Integration/Performance
predecessors are finished or die fast, so they start within seconds; only
Mutation queues behind old Mutation, which is fine for a 30-minute advisory
job. No change to runner usage. actionlint clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VbtaCN1Re14pJ99VFW4R18
…ner' in comments

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VbtaCN1Re14pJ99VFW4R18
…robes (W1 skateboard)

Implements Phase 1 of the Chaos Pain Suite design (branch
docs/chaos-pain-suite-design; plan under docs/plans/). Additive-only on the
uber experiment composition so it transplants onto the rebased-#29 slices
as a file copy - zero edits to #29-owned files.

- ChaosConductor: seeded, replayable action scheduler (STOP_DRAIN /
  STOP_NO_DRAIN / RESTART / JOIN_NEW) with EnumMap-deterministic weighted
  picks, a timestamped action timeline logged every run (the autopsy's
  first artifact), a join-after-stopDrain bias knob (the zombie-drain
  collision the calibration targets), and its own per-instance state
  machine over ManagedPCInstance - including raw closeDrainFirst() for
  DRAIN stops, which the managed API doesn't expose.
- ProgressProbe: independent SLO samplers - progress watermark (30s, with
  tail slack for legitimately-sleeping heavy records), rebalance-dwell
  zombie probe (60s: >> seconds-healthy, << 5-min zombie; keyed on
  protocol-unresponsiveness, NOT partition-holding, which is correct drain
  behaviour), drain-completion bound (150s, must exceed the heavy tail),
  plus the end-of-run correctness ledger (no loss ever; duplicates bounded
  per disturbance, capacity-shaped).
- ChaosChurnStormIT (W1): 12->16 fleet, 80 partitions, 100k messages with
  heavy-tailed work (1-in-4000 records sleeps 90s) - the heavy tail is what
  stretches drains into the probe's discrimination window, since the
  zombie-drain defect freezes the group for the DURATION of a drain.
- ChaosConductorPlanIT: seed-determinism regression (same seed = same plan).
- @tag(chaos) excluded from all default suites (pom default now
  performance,chaos; comment documents the multi-group override gotcha);
  chaos-pain.yml workflow_dispatch runs it on-demand on the highcpu runner
  (seed + reps inputs, artifacts uploaded, never gating).

Validated: 3 green storm runs (500k and 2x100k msgs - zero loss, duplicates
~500-2700 vs allowances), determinism 2/2, default-exclusion verified
(name-matched chaos test runs 0 tests without -Dincluded.groups=chaos).
Calibration against the planted zombie-drain defect arm is the next commit.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VbtaCN1Re14pJ99VFW4R18
…(portable bug-detector pack)

Completes the suite for standalone landing on master:

- ManagedPCInstance extracted from the confluentinc#857 investigation branch (PR #29,
  credited) - the multi-instance PC lifecycle harness; verified
  mainline-API-only. When #29 rebases, its harness slice simply drops its
  copy.
- Suite files at calibrated state: non-interruptible heavy tail (PC's close
  force-interrupts stragglers ~11s, so interruptible sleeps cannot stretch
  drains into a discriminable window), rebalance-dwell ZOMBIE bound 15s set
  from same-seed A/B measurement (healthy peak 6.7s vs defect 20.1s), peak
  signature logging, hotter conductor (0.5-1.5s ticks, join-after-drain
  bias 0.9).

Calibration record (see the design doc on docs/chaos-pain-suite-design and
plan on experiment/chaos-pain-suite-phase1): planted-defect arm 3/3 RED via
ZOMBIE_MEMBER/REBALANCE_BLOCKED (dwell 15.6-15.9s), all-fixes arm 3/3
GREEN (4.5-8.9s), and PLAIN MASTER: RED via the same probe (15.6s) - this
branch's own base carries the drain-zombie bug (fixed on PR #80), and the
suite finds it blind. That is the point: a portable detector, excluded from
every gating suite (@tag chaos), temporarily mergeable into any PR to
expose fix-absent bugs and verify fixes. Run on demand:
-Dincluded.groups=chaos [-Dchaos.seed=N], or the chaos-pain.yml
workflow_dispatch on the highcpu runner.

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

github-actions Bot commented Jul 30, 2026 •

Copy link
Copy Markdown

Dependency Review

The following issues were found:
  • ✅ 0 vulnerable package(s)
  • ✅ 0 package(s) with incompatible licenses
  • ✅ 0 package(s) with invalid SPDX license definitions
  • ⚠️ 3 package(s) with unknown licenses.
See the Details below.

License Issues

.github/workflows/chaos-pain.yml

PackageVersionLicenseIssue Type
actions/checkout6.*.*NullUnknown License
actions/setup-java5.*.*NullUnknown License
actions/upload-artifact7.*.*NullUnknown License
Excluded from license check: pkg:githubactions/actions/github-script

OpenSSF Scorecard

PackageVersionScoreDetails
actions/actions/checkout 6.*.* 🟢 6.9
Details
CheckScoreReason
Binary-Artifacts🟢 10no binaries found in the repo
Code-Review🟢 10all changesets reviewed
Maintained🟢 1025 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 10
Dangerous-Workflow🟢 10no dangerous workflow patterns detected
Token-Permissions⚠️ 0detected GitHub workflow tokens with excessive permissions
CII-Best-Practices⚠️ 0no effort to earn an OpenSSF best practices badge detected
Fuzzing⚠️ 0project is not fuzzed
Pinned-Dependencies🟢 3dependency not pinned by hash detected -- score normalized to 3
License🟢 10license file detected
Packaging⚠️ -1packaging workflow not detected
Signed-Releases⚠️ -1no releases found
Security-Policy🟢 9security policy file detected
Branch-Protection🟢 5branch protection is not maximal on development and all release branches
SAST🟢 10SAST tool is run on all commits
actions/actions/setup-java 5.*.* 🟢 5.3
Details
CheckScoreReason
Maintained🟢 1030 commit(s) and 1 issue activity found in the last 90 days -- score normalized to 10
Code-Review🟢 3Found 7/21 approved changesets -- score normalized to 3
Dangerous-Workflow🟢 10no dangerous workflow patterns detected
Binary-Artifacts🟢 10no binaries found in the repo
Packaging⚠️ -1packaging workflow not detected
CII-Best-Practices⚠️ 0no effort to earn an OpenSSF best practices badge detected
Token-Permissions⚠️ 0detected GitHub workflow tokens with excessive permissions
Pinned-Dependencies⚠️ 0dependency not pinned by hash detected -- score normalized to 0
Fuzzing⚠️ 0project is not fuzzed
License🟢 10license file detected
Signed-Releases⚠️ -1no releases found
Branch-Protection⚠️ 0branch protection not enabled on development/release branches
Security-Policy🟢 9security policy file detected
SAST🟢 9SAST tool is not run on all commits -- score normalized to 9
actions/actions/upload-artifact 7.*.* 🟢 5.2
Details
CheckScoreReason
Code-Review🟢 10all changesets reviewed
Binary-Artifacts🟢 10no binaries found in the repo
Maintained⚠️ 00 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Dangerous-Workflow🟢 10no dangerous workflow patterns detected
Packaging⚠️ -1packaging workflow not detected
CII-Best-Practices⚠️ 0no effort to earn an OpenSSF best practices badge detected
Token-Permissions⚠️ 0detected GitHub workflow tokens with excessive permissions
Pinned-Dependencies⚠️ 1dependency not pinned by hash detected -- score normalized to 1
Fuzzing⚠️ 0project is not fuzzed
License🟢 10license file detected
Signed-Releases⚠️ -1no releases found
Security-Policy🟢 9security policy file detected
SAST🟢 10SAST tool is run on all commits
Branch-Protection⚠️ 0branch protection not enabled on development/release branches

Scanned Files

  • .github/workflows/chaos-pain.yml

@github-actions

github-actions Bot commented Jul 30, 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 33 33 ➖ 0
Duplicated lines 995 995 ➖ 0
Duplication 3.14% 3.14% ➖ 0
Rule Limit Status
Max duplication 5% ✅ Pass (3.14%)
Max increase vs base +0.1% ✅ Pass (+0.00%)

No new clones introduced by this PR.

✅ jscpd (language-agnostic)

PR Base Change
Clones 82 82 ➖ 0
Duplicated lines 1175 1175 ➖ 0
Duplication 3.74% 3.91% 👍 -0.17%
Rule Limit Status
Max duplication 5% ✅ Pass (3.74%)
Max increase vs base +0.1% ✅ Pass (-0.17%)

No new clones introduced by this PR.

Powered by astubbs/duplicate-code-cross-check

@github-actions

github-actions Bot commented Jul 30, 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/io/confluent/parallelconsumer/integrationTests/chaostests/ChaosChurnStormIT.java parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/chaostests/ProgressProbe.java 31.4

🔺 Increased similarities

File A File B Base (%) PR (%) Change
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithEarlyClose.java parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithSaslAuthenticationException.java 50.6 51.8 +1.2
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithCommitTimeoutException.java parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithSaslAuthenticationException.java 47.6 48.6 +1.0
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTest.java parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithSaslAuthenticationException.java 45.2 46.3 +1.0
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java 53.3 54.0 +0.7
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelStreamProcessor.java 35.7 36.3 +0.6
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContextInternal.java 32.9 33.4 +0.5
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PCRetriableException.java 37.1 37.6 +0.5
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContext.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/RecordContextInternal.java 34.6 35.1 +0.5
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java 49.0 49.4 +0.5
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PCRetriableException.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 33.0 33.5 +0.5
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTest.java parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithEarlyClose.java 54.8 55.3 +0.5
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java 43.8 44.2 +0.4
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelStreamProcessor.java parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 31.2 31.6 +0.4
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/TestParallelEoSStreamProcessor.java 30.2 30.6 +0.4
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelStreamProcessor.java 35.4 35.8 +0.4
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTest.java parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithCommitTimeoutException.java 55.8 56.2 +0.4
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContextInternal.java 31.8 32.1 +0.4
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java 59.5 59.9 +0.4
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelStreamProcessor.java 44.4 44.8 +0.3
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 31.3 31.7 +0.3

...and 15 more

Full similarity report
parallel-consumer-core/src/main/java/io/confluent/csid/utils/Java8StreamUtils.java

📄 parallel-consumer-core/src/main/java/io/confluent/csid/utils/Java8StreamUtils.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/csid/utils/JavaUtils.java 34.75
parallel-consumer-core/src/test/java/io/confluent/csid/utils/CollectionUtils.java 32.73
parallel-consumer-core/src/main/java/io/confluent/csid/utils/JavaUtils.java

📄 parallel-consumer-core/src/main/java/io/confluent/csid/utils/JavaUtils.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/csid/utils/CollectionUtils.java 38.99
parallel-consumer-core/src/main/java/io/confluent/csid/utils/Java8StreamUtils.java 34.75
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java 54.01 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 41.37
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java 37.88
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PCRetriableException.java 37.61
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 35.88
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 35.88
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 35.87
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/OffsetDecodingError.java 35.08
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/NoEncodingPossibleException.java 30.41
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java 59.87 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java 53.97 ⚠️
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 39.97
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelStreamProcessor.java 36.33
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContextInternal.java 32.14
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 30.82
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java 59.87 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java 49.44
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelStreamProcessor.java 35.75
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 31.67
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContextInternal.java 30.91
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PCRetriableException.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PCRetriableException.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java 37.61
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 33.47
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 54.89 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java 54.01 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java 45.68
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 35.82
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/OffsetDecodingError.java 34.7
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 31.8
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 31.8
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalRuntimeException.java 30.78
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/NoEncodingPossibleException.java 30.48
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerOptions.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerOptions.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/ProducerManager.java 33.35
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/PartitionState.java 31.85
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java 53.97 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java 49.44
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelStreamProcessor.java 44.79
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContextInternal.java 33.37
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/AbstractParallelEoSStreamProcessor.java 32.84
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/TestParallelEoSStreamProcessor.java 30.58
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelStreamProcessor.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java 44.79
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java 36.33
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java 35.75
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 31.58
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContext.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContext.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/RecordContextInternal.java 35.13
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContextInternal.java 33.1
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContextInternal.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContextInternal.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java 33.37
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContext.java 33.1
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/RecordContextInternal.java 32.48
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java 32.14
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java 30.91
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/RecordContextInternal.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/RecordContextInternal.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContext.java 35.13
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PollContextInternal.java 32.48
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/AbstractParallelEoSStreamProcessor.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/AbstractParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/BrokerPollSystem.java 33.06
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java 32.84
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/BrokerPollSystem.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/BrokerPollSystem.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/AbstractParallelEoSStreamProcessor.java 33.06
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/ExternalEngine.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/ExternalEngine.java

File Similarity (%)
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java 39.61
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java 60.68 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java 54.89 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/OffsetDecodingError.java 51.35 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/NoEncodingPossibleException.java 48.43
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java 41.37
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalRuntimeException.java 38.82
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 37.96
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 34.6
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 34.6
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/PCRetriableException.java 33.47
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalRuntimeException.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalRuntimeException.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 38.82
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java 31.48
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java 30.78
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/PCModule.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/PCModule.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/PCModuleTestEnv.java 32.68
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/ProducerManager.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/ProducerManager.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerOptions.java 33.35
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java 52.45 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 38.32
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 38.32
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 37.96
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java 35.87
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java 35.82
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/OffsetDecodingError.java 34.03
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/NoEncodingPossibleException.java 30.33
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 60.68 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 52.45 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/OffsetDecodingError.java 49.45
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 48.03
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 48.03
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/NoEncodingPossibleException.java 47.09
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java 45.68
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java 37.88
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalRuntimeException.java 31.48
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/NoEncodingPossibleException.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/NoEncodingPossibleException.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 48.43
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java 47.09
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/OffsetDecodingError.java 45.69
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 39.16
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 39.16
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java 30.48
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java 30.41
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 30.33
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/OffsetDecodingError.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/OffsetDecodingError.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 51.35 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java 49.45
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/NoEncodingPossibleException.java 45.69
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java 35.08
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java 34.7
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 34.03
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 32.75
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 32.75
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java 64.26 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java 48.03
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/NoEncodingPossibleException.java 39.16
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 38.32
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java 35.88
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 34.6
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/OffsetDecodingError.java 32.75
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java 31.8
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV2EncodingNotSupported.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/RunLengthV1EncodingNotSupported.java 64.26 ⚠️
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/EncodingNotSupportedException.java 48.03
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/NoEncodingPossibleException.java 39.16
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/BitSetEncodingNotSupportedException.java 38.32
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ExceptionInUserFunctionException.java 35.88
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/InternalException.java 34.6
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/offsets/OffsetDecodingError.java 32.75
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerException.java 31.8
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/PartitionState.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/PartitionState.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerOptions.java 31.85
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/PartitionStateManager.java 31.0
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/PartitionStateManager.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/PartitionStateManager.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/WorkManager.java 42.38
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/PartitionState.java 31.0
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/ProcessingShard.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/ProcessingShard.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/ShardManager.java 38.68
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/ShardManager.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/ShardManager.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/ProcessingShard.java 38.68
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/WorkManager.java

📄 parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/WorkManager.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/PartitionStateManager.java 42.38
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/KafkaSanityTests.java

📄 parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/KafkaSanityTests.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/csid/utils/LoopingResumingIteratorTest.java 33.95
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java

📄 parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java 55.49 ⚠️
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java 46.99
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java 38.69
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java

📄 parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java 44.22
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java 40.99
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java 38.69
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/RebalanceEoSDeadlockTest.java

📄 parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/RebalanceEoSDeadlockTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/RebalanceTest.java 36.61
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/RebalanceTest.java

📄 parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/RebalanceTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/RebalanceEoSDeadlockTest.java 36.61
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java

📄 parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java 60.7 ⚠️
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java 46.99
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java 40.99
parallel-consumer-vertx/src/test-integration/java/io/confluent/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java 30.07
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java

📄 parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java 60.7 ⚠️
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceHighVolumeTest.java 55.49 ⚠️
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/MultiInstanceRebalanceTest.java 44.22
parallel-consumer-vertx/src/test-integration/java/io/confluent/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java 39.38
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/chaostests/ChaosChurnStormIT.java

📄 parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/chaostests/ChaosChurnStormIT.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/chaostests/ProgressProbe.java 31.44
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/chaostests/ProgressProbe.java

📄 parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/chaostests/ProgressProbe.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/chaostests/ChaosChurnStormIT.java 31.44
parallel-consumer-core/src/test/java/io/confluent/csid/utils/CollectionUtils.java

📄 parallel-consumer-core/src/test/java/io/confluent/csid/utils/CollectionUtils.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/csid/utils/JavaUtils.java 38.99
parallel-consumer-core/src/main/java/io/confluent/csid/utils/Java8StreamUtils.java 32.73
parallel-consumer-core/src/test/java/io/confluent/csid/utils/LoopingResumingIteratorTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/csid/utils/LoopingResumingIteratorTest.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/KafkaSanityTests.java 33.95
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/BatchTestBase.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/BatchTestBase.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/CoreBatchTest.java 30.13
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/CheckQuarantineOwnersScriptTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/CheckQuarantineOwnersScriptTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/QuarantineLaneReportScriptTest.java 45.8
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/QuarantineRegistryScriptTest.java 44.36
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/CoreBatchTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/CoreBatchTest.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorBatchTest.java 52.03 ⚠️
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyBatchTest.java 50.73 ⚠️
parallel-consumer-vertx/src/test/java/io/confluent/parallelconsumer/vertx/VertxBatchTest.java 44.76
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/BatchTestBase.java 30.13
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithCommitTimeoutException.java 56.22 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithEarlyClose.java 55.28 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithSaslAuthenticationException.java 46.26
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithCommitTimeoutException.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithCommitTimeoutException.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithEarlyClose.java 70.4 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTest.java 56.22 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithSaslAuthenticationException.java 48.63
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithEarlyClose.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithEarlyClose.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithCommitTimeoutException.java 70.4 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTest.java 55.28 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithSaslAuthenticationException.java 51.75 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithSaslAuthenticationException.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithSaslAuthenticationException.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithEarlyClose.java 51.75 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTestWithCommitTimeoutException.java 48.63
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/MockConsumerTest.java 46.26
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/ParallelEoSSStreamProcessorRebalancedTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/ParallelEoSSStreamProcessorRebalancedTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessorTest.java 34.76
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessorTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessorTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/ParallelEoSSStreamProcessorRebalancedTest.java 34.76
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/QuarantineLaneReportScriptTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/QuarantineLaneReportScriptTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/CheckQuarantineOwnersScriptTest.java 45.8
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/QuarantineRegistryScriptTest.java 33.89
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/QuarantineRegistryScriptTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/QuarantineRegistryScriptTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/CheckQuarantineOwnersScriptTest.java 44.36
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/QuarantineLaneReportScriptTest.java 33.89
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/TestConventionsArchTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/TestConventionsArchTest.java

File Similarity (%)
parallel-consumer-vertx/src/test/java/io/confluent/parallelconsumer/vertx/TestConventionsArchTest.java 90.47 ⚠️
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/TestConventionsArchTest.java 89.8 ⚠️
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/TestConventionsArchTest.java 89.8 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/ExceptionConstructorsTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/ExceptionConstructorsTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/InternalRuntimeExceptionTest.java 30.81
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/InternalRuntimeExceptionTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/InternalRuntimeExceptionTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/ExceptionConstructorsTest.java 30.81
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/PCModuleTestEnv.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/PCModuleTestEnv.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/PCModule.java 32.68
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/TestParallelEoSStreamProcessor.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/internal/TestParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelEoSStreamProcessor.java 30.58
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/offsets/OffsetEncodingBackPressureTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/offsets/OffsetEncodingBackPressureTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/offsets/OffsetEncodingBackPressureUnitTest.java 40.3
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/offsets/OffsetEncodingBackPressureUnitTest.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/offsets/OffsetEncodingBackPressureUnitTest.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/offsets/OffsetEncodingBackPressureTest.java 40.3
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/truth/CommitHistorySubject.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/truth/CommitHistorySubject.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/truth/LongPollingMockConsumerSubject.java 36.61
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/truth/LongPollingMockConsumerSubject.java

📄 parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/truth/LongPollingMockConsumerSubject.java

File Similarity (%)
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/truth/CommitHistorySubject.java 36.61
parallel-consumer-mutiny/src/main/java/io/confluent/parallelconsumer/mutiny/MutinyProcessor.java

📄 parallel-consumer-mutiny/src/main/java/io/confluent/parallelconsumer/mutiny/MutinyProcessor.java

File Similarity (%)
parallel-consumer-reactor/src/main/java/io/confluent/parallelconsumer/reactor/ReactorProcessor.java 53.46 ⚠️
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyBatchTest.java

📄 parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyBatchTest.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorBatchTest.java 79.14 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/CoreBatchTest.java 50.73 ⚠️
parallel-consumer-vertx/src/test/java/io/confluent/parallelconsumer/vertx/VertxBatchTest.java 49.43
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyPCTest.java

📄 parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyPCTest.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorPCTest.java 69.59 ⚠️
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyTest.java

📄 parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyTest.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorTest.java 34.09
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyUnitTestBase.java

📄 parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyUnitTestBase.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorUnitTestBase.java 33.11
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/TestConventionsArchTest.java

📄 parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/TestConventionsArchTest.java

File Similarity (%)
parallel-consumer-vertx/src/test/java/io/confluent/parallelconsumer/vertx/TestConventionsArchTest.java 91.31 ⚠️
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/TestConventionsArchTest.java 90.64 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/TestConventionsArchTest.java 89.8 ⚠️
parallel-consumer-reactor/src/main/java/io/confluent/parallelconsumer/reactor/ReactorProcessor.java

📄 parallel-consumer-reactor/src/main/java/io/confluent/parallelconsumer/reactor/ReactorProcessor.java

File Similarity (%)
parallel-consumer-mutiny/src/main/java/io/confluent/parallelconsumer/mutiny/MutinyProcessor.java 53.46 ⚠️
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorBatchTest.java

📄 parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorBatchTest.java

File Similarity (%)
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyBatchTest.java 79.14 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/CoreBatchTest.java 52.03 ⚠️
parallel-consumer-vertx/src/test/java/io/confluent/parallelconsumer/vertx/VertxBatchTest.java 50.69 ⚠️
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorPCTest.java

📄 parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorPCTest.java

File Similarity (%)
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyPCTest.java 69.59 ⚠️
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorTest.java

📄 parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorTest.java

File Similarity (%)
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyTest.java 34.09
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorUnitTestBase.java

📄 parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorUnitTestBase.java

File Similarity (%)
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyUnitTestBase.java 33.11
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/TestConventionsArchTest.java

📄 parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/TestConventionsArchTest.java

File Similarity (%)
parallel-consumer-vertx/src/test/java/io/confluent/parallelconsumer/vertx/TestConventionsArchTest.java 91.31 ⚠️
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/TestConventionsArchTest.java 90.64 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/TestConventionsArchTest.java 89.8 ⚠️
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java

📄 parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java 41.29
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java 39.97
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 39.07
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelStreamProcessor.java 34.88
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelStreamProcessor.java 31.67
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java

📄 parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java

File Similarity (%)
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 39.07
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelStreamProcessor.java 38.23
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelStreamProcessor.java 31.58
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/JStreamParallelEoSStreamProcessor.java 30.82
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java

📄 parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java

File Similarity (%)
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelStreamProcessor.java 41.54
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 41.29
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/ExternalEngine.java 39.61
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelStreamProcessor.java

📄 parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelStreamProcessor.java

File Similarity (%)
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java 41.54
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelStreamProcessor.java 38.23
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/JStreamVertxParallelEoSStreamProcessor.java 34.88
parallel-consumer-vertx/src/test-integration/java/io/confluent/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java

📄 parallel-consumer-vertx/src/test-integration/java/io/confluent/parallelconsumer/vertx/integrationTests/VertxConcurrencyIT.java

File Similarity (%)
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/VeryLargeMessageVolumeTest.java 39.38
parallel-consumer-core/src/test-integration/java/io/confluent/parallelconsumer/integrationTests/TransactionAndCommitModeTest.java 30.07
parallel-consumer-vertx/src/test/java/io/confluent/parallelconsumer/vertx/TestConventionsArchTest.java

📄 parallel-consumer-vertx/src/test/java/io/confluent/parallelconsumer/vertx/TestConventionsArchTest.java

File Similarity (%)
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/TestConventionsArchTest.java 91.31 ⚠️
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/TestConventionsArchTest.java 91.31 ⚠️
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/TestConventionsArchTest.java 90.47 ⚠️
parallel-consumer-vertx/src/test/java/io/confluent/parallelconsumer/vertx/VertxBatchTest.java

📄 parallel-consumer-vertx/src/test/java/io/confluent/parallelconsumer/vertx/VertxBatchTest.java

File Similarity (%)
parallel-consumer-reactor/src/test/java/io/confluent/parallelconsumer/reactor/ReactorBatchTest.java 50.69 ⚠️
parallel-consumer-mutiny/src/test/java/io/confluent/parallelconsumer/mutiny/MutinyBatchTest.java 49.43
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/CoreBatchTest.java 44.76

@github-actions

Copy link
Copy Markdown

✅ SpotBugs Report

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

astubbs and others added 2 commits July 30, 2026 16:24
…it; nothing is 'planted'/injected

'Planted' (mutation-testing jargon) wrongly implied synthetic fault
insertion. The defect arm is git archaeology: the genuine historical bug in
its original code, selected by basing on the pre-fix commit. The only
engineered element is the sensitizing workload (non-interruptible heavy
tail) that makes the real defect's freeze long enough to discriminate.

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

Detects protocol-INVISIBLE stalls: group STABLE, heartbeats + polls flowing,
no rebalance pending (so the broker's 5-min eviction clock never starts), yet
a partition's lag is real and its committed offset stops moving - the 'locks
forever until manual restart' class from the confluentinc#857 reports, which the Class 1
zombie probe cannot see.

Mechanism: every 5th sampler tick, admin listConsumerGroupOffsets vs
listOffsets(latest); violation CLASS2_STALL/LAG_STAGNATION when lag >= 50 and
the committed offset has been stagnant > 150s. Peak (maxLagStagnation) logged
every run.

Calibration so far (test-the-test discipline):
- First healthy run FIRED at 151s: a real measurement, not a probe bug - a
  hard stop interrupts a heavy record mid-dwell and at-least-once re-runs it
  fresh, legitimately blocking that partition ~2 chained dwells. Fix per the
  calibrate-the-workload lesson: heavy dwell 90s -> 45s (the zombie window
  only needs drains occupied; close bails at ~11s regardless), so a 2-dwell
  redelivery chain (~90s) fits under the 150s bound. Arithmetic recorded in
  both javadocs.
- Re-validated: healthy arm 2/2 GREEN (peak lag stagnation ~39s, ~4x margin);
  defect arm still RED on ZOMBIE_MEMBER with unchanged dwell signature
  (15.7s vs 15.6-15.9s at the old 90s dwell).
- RED calibration of this probe awaits the W4 revoke-under-work trigger
  scenario (next Phase 2 step).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VbtaCN1Re14pJ99VFW4R18
… the pom

The gating scripts hardcode -Dexcluded.groups (overriding the pom default),
so adding 'chaos' only to the pom let ChaosChurnStormIT leak into the
required Integration Tests check - where it promptly went RED on this
branch's master base (the detector detecting; but it must not gate).

Same class of bug the quarantine-lane PR #84's contract test now pins for
the 'quarantined' group.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VbtaCN1Re14pJ99VFW4R18
@claude

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

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


Code review — PR #83 (Chaos Pain Suite)

Todo list

  • Gather context (PR body, comments, changed files list)
  • Check out branch and inspect diff vs origin/master
  • Read repo conventions (AGENTS.md — no CLAUDE.md present)
  • Review core suite logic (ChaosConductor, ProgressProbe, ChaosChurnStormIT, ManagedPCInstance, determinism/ledger tests)
  • Review CI wiring (pom.xml, bin/ci-*.sh, chaos-pain.yml, maven.yml)
  • Post review feedback

This is a well-engineered, heavily self-documented suite — the determinism rework (TickDraws consumed in full every tick regardless of live state) and the ledger/probe calibration arithmetic are sound, and prior review rounds have clearly already caught most of the sharp edges (teardown races, vacuous-bound guard, PROBE_DEGRADED, etc.). One concrete bug survived, though, and it's in the part of the PR that's supposed to prove the suite works.

🔴 chaos-pain.yml currently runs zero tests (silently reports success)

.github/workflows/chaos-pain.yml:83:

-Dincluded.groups=chaos -Dexcluded.groups=quarantined

ChaosChurnStormIT.churnStormMeetsSlosAndBalancesLedger is the only test tagged chaos right now, and it's also annotated @Quarantined (parallel-consumer-core/.../ChaosChurnStormIT.java:93-100), which expands to @Tag("quarantined"). JUnit5/Surefire-Failsafe tag filtering always applies exclusion after inclusion — a test matching an included tag is still dropped if it also matches an excluded tag. So -Dincluded.groups=chaos -Dexcluded.groups=quarantined selects zero tests. maven-failsafe-plugin's failIfNoTests defaults to false, so the job reports green with nothing having run — during exactly the window (pre-#80) the PR's whole calibration story depends on it running and going RED.

This is a real drift, not a deliberate choice: every sibling script gets it right by leaving excluded.groups empty when targeting a group that might overlap with quarantined:

  • bin/quarantined-test.sh:42-43 — -Dincluded.groups=quarantined -Dexcluded.groups=
  • bin/performance-test.sh:19-20 — -Dincluded.groups=performance -Dexcluded.groups=
  • AGENTS.md's own documented "Run locally" command for this suite — -Dincluded.groups=chaos -Dexcluded.groups=
  • docs/inflight.md:72 — same, and it describes chaos-pain.yml as equivalent to that command (it currently isn't)

Fix: change -Dexcluded.groups=quarantined to -Dexcluded.groups= (empty) at .github/workflows/chaos-pain.yml:83, matching the established pattern. (Note: per the task instructions I can't push changes to .github/workflows/* myself — GitHub App permissions block workflow file edits.)

Fix this →

Minor / informational (not blocking)

  • ChaosConductor.joinDrainers() / ChaosChurnStormIT settle loop (ChaosConductor.java:217-234, ChaosChurnStormIT.java:182-196): if a STOP_DRAIN's background closeDrainFirst() outlives the 60s DRAINER_JOIN_BUDGET (already logged loudly as a timeline entry when it happens), the test's own settle loop only waits on ManagedPCInstance.isClosePending() — which is set by stopAsync(), not by the conductor's raw closeDrainFirst() path. In that rare edge case the settle loop could call parallelConsumer.close() concurrently with the still-running drain thread. Given the budget is documented to "exceed the heaviest legitimate drain" and the overrun is already surfaced in the timeline, this is a narrow, already-flagged risk rather than a fix-blocking bug — just noting it since it wasn't called out explicitly elsewhere.
  • chaos-pain.yml's header comment ("a RED here is a real finding - the suite is calibrated GREEN on both assignors") is now stale relative to the PR body/quarantine state (the suite is expected RED pre-fix(core): draining PC stops polling - 10kHz busy-spin + zombie partition hold (#857-family silent stall) #80). Once the group-filter fix above lands and fix(core): draining PC stops polling - 10kHz busy-spin + zombie partition hold (#857-family silent stall) #80 merges, worth a pass to make sure the workflow comments and AGENTS.md/docs/inflight.md framing agree on current expected state.

Everything else — ChaosConductor's draw-consumption model, ProgressProbe's SLO math and calibration javadocs, the ledger's vacuous-bound cap, ManagedPCInstance's extraction, and the CI script/pom group-exclusion wiring (bin/ci-*.sh, pom.xml) — checked out clean.

No workflow targets [self-hosted, macOS] anymore - the mac fast-feedback
lane was superseded by the grumpy/highcpu workflows.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK
@claude

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

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


Claude finished @antony Stubbs's task

Todo list

  • Gather context (PR body, comments, changed files list)
  • Check out branch and inspect diff vs origin/master
  • Read AGENTS.md / repo conventions
  • Run code review (correctness, testing, maintainability, standards)
  • Post review feedback

Review

Reviewed the diff (origin/master...HEAD, 25 files) with focus on the new chaos-suite code (ChaosConductor, ProgressProbe, ChaosChurnStormIT, ManagedPCInstance, the two new gating ITs) since that's the substance of this PR; the CI/workflow files carried in from the #75 stack are out of scope here.

The core design is solid and the a52fd9e "review hardening" commit already closed the determinism gap I'd have flagged first — ChaosConductorPlanIT now exercises the real drawTick production path and gates every integration build, and the tick-draw-consumed-unconditionally-per-tick approach in ChaosConductor.loop() (parallel-consumer-core/.../ChaosConductor.java:248-274) is the right fix for seed replay: the bias/target rolls are always drawn, only the realized action is filtered by live fleet state, so the RNG stream truly is a pure function of (seed, tick index).

1. Shell/script-injection risk in the new chaos-pain.yml (medium, self-hosted runner)

.github/workflows/chaos-pain.yml:76:

if [ -n "${{ inputs.seed }}" ]; then SEED_ARG="-Dchaos.seed=${{ inputs.seed }}"; fi

${{ inputs.seed }} is substituted as raw text into the run: block before the shell parses it — a workflow_dispatch seed value containing backticks or $(...) executes as shell code on the self-hosted highcpu runner. This file already reasons carefully about RCE risk for fork PRs (guarding on head.repo.full_name), so it's worth closing this gap too, even though workflow_dispatch is write-access-gated (defense in depth — a compromised/careless token with write-but-not-admin access, or a future relaxation of that gate, would otherwise get runner RCE for free). Fix: pass the input through env: and reference the shell variable instead of interpolating the template expression directly, e.g.

env:
  CHAOS_SEED: ${{ inputs.seed }}
run: |
  ...
  if [ -n "$CHAOS_SEED" ]; then SEED_ARG="-Dchaos.seed=$CHAOS_SEED"; fi

Fix this →

2. MDC.put without cleanup in ManagedPCInstance.run() (low, log hygiene, pre-existing pattern)

parallel-consumer-core/.../ManagedPCInstance.java:84 sets MDC.put(MDC_INSTANCE_ID, "Runner-" + instanceId) but never MDC.remove(...) when run() completes. pcExecutor is a newWorkStealingPool() (ChaosChurnStormIT.java:125), so pool threads are reused across different ManagedPCInstances over the run — a later restart on a reused thread can inherit a stale Runner-N MDC value until that thread's own run() re-sets it, which can misattribute log lines during the window between restarts. Doesn't affect correctness of the suite itself, just worth a try { ... } finally { MDC.remove(MDC_INSTANCE_ID); } if this file gets touched again (this was extracted "with credit" from the confluentinc#857 investigation branch, so this may be pre-existing behavior rather than newly introduced here).

3. Ledger duplicate allowance is very loose at this scenario's scale (informational, already reasoned about)

ChaosChurnStormIT.java:224-225 calls ProgressProbe.ledger(expectedKeys, allConsumed, Math.max(disturbances, 1), 5_000). With EXPECTED_MESSAGES=100_000 and a churny 5-minute run plausibly producing dozens+ of disturbances, rawAllowance (disturbances × 5000) very likely blows past the half-of-expected cap (50,000) added in the hardening pass — meaning in practice the duplicate check degrades to "duplicates ≤ 50% of everything produced." That's clearly intentional per the PR's own commit note ("vacuous-bound guard," not a tightening), and record-loss (the zero-tolerance half of the ledger) is the check doing the real work, so this is just worth knowing: the duplicate bound likely won't fire in this scenario's realistic disturbance range even with a real duplicate-amplification regression. Not requesting a change — flagging for awareness given the ledger is billed as "no record ever lost; duplicates bounded."

Nothing else stood out. ProgressProbe's three SLO samplers (progress watermark, rebalance-dwell, Class 2 lag-stagnation) and the ledger() boundary math (now covered by ProgressProbeLedgerIT) look correct, including the re-arm-after-violation logic and the PROBE_DEGRADED false-GREEN guard. ChaosConductor's state machine (RUNNING/DRAINING/STOPPED, pickInState scoped away from the protected instance) has no races I could find — all state transitions happen on the single conductor thread except the drain-completion flip to STOPPED, which is exactly the one that must happen off-thread. The calibration story in the PR body (measured RED/GREEN peaks, threshold set in the empirical gap, workload retuned rather than probe loosened after the 151s false-positive) is exactly the rigor this kind of suite needs to be trustworthy.

Reply to a review comment in its own thread and mark it resolved when addressed, rather than a top-level PR comment (which leaves the conversation unresolved and blocks merge). Recording the rule that surfaced while handling PR #75 review feedback.

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

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

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


Code review — PR #83 (Chaos Pain Suite)

Todo list

  • Gather context (PR body, comments, changed files list)
  • Check out branch and inspect diff vs origin/master
  • Read repo conventions (AGENTS.md)
  • Review core suite logic (ChaosConductor, ProgressProbe, ChaosChurnStormIT, ManagedPCInstance, ChaosConductorPlanIT, ProgressProbeLedgerIT)
  • Review CI wiring (pom.xml, bin/ci-*.sh, chaos-pain.yml)
  • Post review feedback

Only two commits landed since the last full review round (7050958 actionlint tidy, 06db3dc a one-line AGENTS.md policy note) — no changes to the suite itself. I independently re-read ChaosConductor, ProgressProbe, ChaosChurnStormIT, ManagedPCInstance, ChaosConductorPlanIT and ProgressProbeLedgerIT in full: the deterministic draw-consumption model, the ledger's vacuous-bound cap, the drain-thread join/teardown ordering, and isExpectedCloseException's whitelist all check out — no new correctness issues found.

🔴 Still open: chaos-pain.yml currently selects zero tests, and docs describe it as running the full suite

.github/workflows/chaos-pain.yml:83:

-Dincluded.groups=chaos -Dexcluded.groups=quarantined

ChaosChurnStormIT.churnStormMeetsSlosAndBalancesLedger is the only @Tag("chaos") test and is now also @Quarantined (→ @Tag("quarantined"), added in c3ba4e1). JUnit5/Failsafe always applies exclusion after inclusion, so this selects zero tests; failIfNoTests is never set anywhere in the pom/scripts (confirmed via grep), so it defaults to false and the job reports green having run nothing.

I can see from c3ba4e1's commit message this is a deliberate, understood tradeoff — quarantined is excluded from the per-PR-commit run specifically so the known #80-pending RED doesn't drown out the "ambient tripwire" signal on every push to this branch, and the message explicitly notes "until W4 variants... or the #80 fix land, #83's chaos-pain job has zero chaos tests to run." So this isn't an oversight in the workflow itself. But two gaps remain from that tradeoff:

  1. Docs still claim equivalence that isn't true right now. AGENTS.md:99 ("Run locally") and docs/inflight.md:71-72 both document -Dexcluded.groups= (empty) as the canonical invocation and describe chaos-pain.yml as running that same thing — matching the convention every other script follows (bin/ci-build.sh:29, bin/ci-integration-test.sh:26, bin/ci-unit-test.sh:24, bin/quarantined-test.sh all exclude quarantined only when not targeting chaos/quarantined specifically). A reader of either doc has no way to learn that the on-demand/per-PR chaos job is currently a no-op.
  2. The zero-selection state is silent. Nothing in the job (summary, log line, or a failIfNoTests=true + expected-count check) makes "0 tests ran" visible — it looks identical to a real GREEN run in the Checks UI. Given this PR's whole pitch is "reds on master today, on first contact," a CI consumer skimming the checks tab for this exact workflow currently sees a false-safe green.

Given c3ba4e1's own framing, the likely intended fix is on the docs side (note the temporary chaos-pain.yml/local-recipe divergence and the expected zero-test window until #80/W4 land) plus a cheap CI-side tripwire (print the selected test count, or set failIfNoTests=true and treat 0-tests as an explicit non-failure-but-flagged state) rather than reverting the exclusion. As before, this is a workflow file I can't push to directly (GitHub App permissions block .github/workflows/* edits) — flagging for @astubbs to action.

Fix this →

Everything else

ChaosConductor's TickDraws consumption, pickInState's target-roll modulo, joinDrainers' budget accounting, ProgressProbe's SLO math (rebalance dwell, drain bound, Class 2 lag-stagnation re-arm), the ledger's duplicate-allowance cap, ManagedPCInstance's exception whitelist and closePending semantics, and the CI script/pom group-exclusion wiring for every other script — all checked out clean, consistent with the prior review round's findings. No new issues surfaced.

Addresses the Claude auto-review findings on PR #83:

1. chaos-pain.yml: workflow_dispatch inputs (seed, reps) now pass through
   env vars instead of ${{ }} template substitution inside run: - raw
   interpolation executes attacker-shaped input as shell on the
   self-hosted runner (the review flagged seed; reps had the same
   vector). Also ${SEED_ARG:+...} quoting per shellcheck.
2. ManagedPCInstance.run(): try/finally MDC.remove - work-stealing pool
   threads are reused across instances, so the Runner-N tag leaked into
   later instances' setup logs between restarts.

Finding 3 (loose ledger duplicate allowance) intentionally unchanged: it
is the documented vacuous-bound guard; the evidence-based tightening is
rostered in docs/inflight.md behind revoke-event instrumentation.

Verified: test-compile clean, actionlint clean.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK
@claude

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

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


Code review — PR #83 (Chaos Pain Suite)

Todo list

  • Gather context (PR body, comments, changed files list)
  • Check out branch and inspect diff vs origin/master since last review round
  • Re-verify prior review findings (chaos-pain.yml zero-test issue, injection fix, MDC leak)
  • Review new/changed code since last review
  • Post review feedback

Only one commit landed since the last review round: c2ce517 ("review follow-ups - workflow input injection + MDC leak"). I re-read both changed files in full plus the surrounding call paths.

✅ Both targeted fixes are correct

  • chaos-pain.yml injection fix (.github/workflows/chaos-pain.yml:76-89): seed/reps now flow through env: (CHAOS_SEED/CHAOS_REPS) instead of ${{ }} template substitution inside run:, and ${SEED_ARG:+"$SEED_ARG"} avoids the unquoted-expansion/word-splitting footgun. This closes the RCE vector on the self-hosted highcpu runner correctly — env vars are data, template expressions are code-before-the-shell-sees-it.
  • ManagedPCInstance.run() MDC leak (ManagedPCInstance.java:84-146): the try/finally now wraps the whole body including the early-return path (interrupted while waiting on the previous PC's close), so MDC.remove(MDC_INSTANCE_ID) runs on every exit, not just the happy path. Note for awareness (not a bug in this commit): parallelConsumer.poll(...) (ParallelEoSStreamProcessor.poll → supervisorLoop) is non-blocking — it submits the control loop to an executor and returns immediately — so run() (and thus this finally) completes almost as soon as setup finishes, well before the instance actually starts/stops processing. That's pre-existing behavior, not something this fix changes; the fix is still correct for what it targets (preventing a stale Runner-N tag from leaking into other tasks that later reuse the same pcExecutor work-stealing-pool thread), just worth knowing the tag doesn't cover the instance's full async lifetime.

🔴 Still open: chaos-pain.yml selects zero tests (flagged in two earlier review rounds, unchanged)

.github/workflows/chaos-pain.yml:88:

-Dincluded.groups=chaos -Dexcluded.groups=quarantined

ChaosChurnStormIT is still the only @Tag("chaos") test and is still @Quarantined (→ @Tag("quarantined"), confirmed via Quarantined.java:41). JUnit5/Failsafe applies exclusion after inclusion, so this selects zero tests, and failIfNoTests isn't set anywhere (confirmed via grep across pom.xml), so the job reports green having run nothing — on both the workflow_dispatch and per-PR-commit pull_request triggers.

This was already raised twice and acknowledged as an intentional interim tradeoff in commit c3ba4e1's message (avoid the known #80-pending RED drowning the tripwire signal), with two follow-ups requested that are still outstanding:

  1. AGENTS.md:99 and docs/inflight.md:71-72 still document the local recipe (-Dexcluded.groups=, i.e. not excluding quarantined) as what chaos-pain.yml runs — that's currently false; no note anywhere flags the temporary zero-test window.
  2. Nothing in the job surfaces "0 tests selected" — it's visually identical to a real GREEN run in the Checks UI.

Given this PR's core pitch is "reds on master today, on first contact," the on-demand/per-PR-commit chaos job is currently unable to demonstrate that. Since c2ce517 deliberately fixed the two other review-2 findings and left this one alone (it's a different issue, from review rounds 1 and 3), this looks like it just hasn't been gotten to yet rather than a considered rejection — worth a decision either way before merge: either drop -Dexcluded.groups=quarantined (matching every sibling script's convention) or add the doc caveat + a visible zero-tests signal.

Fix this →

Everything else

No other issues found in this round. The rest of the suite (ChaosConductor's deterministic draw model, ProgressProbe's SLO math, the ledger's vacuous-bound cap, ChaosConductorPlanIT/ProgressProbeLedgerIT gating tests) is unchanged since the prior clean passes and wasn't re-flagged.

@astubbs

astubbs commented Jul 31, 2026

Copy link
Copy Markdown
Owner Author

Review response (re: the auto-review) - addressed in c2ce517

1. Shell injection in chaos-pain.yml - FIXED (and widened). Both workflow_dispatch inputs now pass through env: and are referenced as quoted shell variables - the review flagged seed, but reps had the identical raw-interpolation vector two lines down, so both are fixed. Also switched the mvn arg to ${SEED_ARG:+"$SEED_ARG"} (shellcheck SC2086).

2. MDC leak in ManagedPCInstance.run() - FIXED. The whole run() body is now try { } finally { MDC.remove(MDC_INSTANCE_ID); }, covering the early-return interrupt path too - reused work-stealing pool threads no longer carry a stale Runner-N tag into later instances' logs.

3. Ledger duplicate allowance - intentionally unchanged, as the review anticipated. It's the documented vacuous-bound guard (record-loss zero-tolerance does the real work). The evidence-based tightening is rostered in docs/inflight.md behind the revoke-event instrumentation follow-up: once revoke counts are logged per run, the allowance can be set from measured duplicate arithmetic instead of a guess.

Verified before push: mvn test-compile clean, actionlint clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK

…hecklist gate (#97)

Resolutions: newer #97 checklist wording in CHANGELOG/README/AGENTS (keeping
this branch's in-thread review-response policy bullet alongside); ci scripts
keep the chaos-inclusive exclusion list per the quarantine contract test.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK
@claude

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

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


Code review — PR #83 (Chaos Pain Suite)

Todo list

  • Gather context (PR body, comments, prior review rounds, changed files list)
  • Check out branch and inspect diff vs origin/master
  • Run code review against current HEAD
  • Post review feedback

Summary

Since the last full review round (c2ce517), the only commit that landed is ce87cd4, a merge of master into this branch to pick up PR #97 (PR-checklist gate) and #75. Confirmed via git diff c2ce517..HEAD --stat: it touches only .github/workflows/pr-checklist.yml, .github/PULL_REQUEST_TEMPLATE.md, AGENTS.md (2 lines), CHANGELOG.adoc, README.adoc — none of the chaos-suite's own files (ChaosConductor, ProgressProbe, ChaosChurnStormIT, ManagedPCInstance, ChaosConductorPlanIT, ProgressProbeLedgerIT, chaos-pain.yml, pom.xml, bin/ci-*.sh) changed. Those were already re-read in full across the prior four review rounds (correctness, determinism model, ledger math, CI wiring, the injection + MDC fixes) with no outstanding issues besides the one below.

🔴 Still open: chaos-pain.yml selects zero tests

.github/workflows/chaos-pain.yml:88 (unchanged, confirmed by reading the current file):

-Dincluded.groups=chaos -Dexcluded.groups=quarantined

ChaosChurnStormIT remains the only @Tag("chaos") test and is also @Quarantined (→ @Tag("quarantined")), added in c3ba4e1 to hold the known #80-pending RED. JUnit5/Failsafe applies tag exclusion after inclusion, so this combination still selects zero tests, and failIfNoTests isn't set anywhere in the pom/scripts, so both the workflow_dispatch and per-PR-commit pull_request runs of this job report green having executed nothing.

This has been raised in three prior review rounds and acknowledged in c3ba4e1's commit message as a deliberate interim tradeoff (don't let the known #80 RED drown the ambient tripwire signal), but the two follow-ups from those rounds are still outstanding and unaddressed:

  1. AGENTS.md:99 and docs/inflight.md:71-72 still document the local recipe (-Dexcluded.groups=, empty) as equivalent to what chaos-pain.yml runs — currently false, and nothing flags the zero-test window.
  2. Nothing in the job (summary, log, or failIfNoTests) makes "0 tests selected" visible — it's indistinguishable from a real GREEN run in the Checks UI, for a PR whose entire pitch is "reds on master today, on first contact."

The header comment at chaos-pain.yml:12-13 ("a RED here is a real finding - the suite is calibrated GREEN on both assignors") is also still stale against this reality.

As before, either drop -Dexcluded.groups=quarantined (matching every sibling script's convention: bin/quarantined-test.sh, bin/performance-test.sh) or keep the exclusion deliberately and add the doc caveat + a visible zero-tests signal — this is a decision for @astubbs, not something I can silently resolve. I can't push this fix myself: GitHub App permissions block .github/workflows/* edits.

Fix this →

Everything else

No new issues found this round. All previously-reviewed areas remain clean and unchanged: ChaosConductor's deterministic TickDraws consumption, ProgressProbe's SLO math (progress watermark, rebalance-dwell, Class 2 lag-stagnation), the ledger's vacuous-bound cap, ManagedPCInstance's exception whitelist and the fixed MDC leak, the chaos-pain.yml workflow-input injection fix (env: + quoted shell vars), and the CI script/pom group-exclusion wiring in bin/ci-*.sh / pom.xml.

The PR-checklist gate (now on master via #97) requires it - and the suite
is changelog-worthy by house style (CI/dev-facing entries are in).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK
@claude

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

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


Code review — PR #83 (Chaos Pain Suite)

Todo list

  • Gather context (PR body, prior review rounds, changed files)
  • Check out branch and diff since last reviewed commit (ce87cd4)
  • Re-verify the previously-flagged chaos-pain.yml zero-test issue is still present
  • Post review feedback

Summary

The only commit since the last full review round (c2ce517, and the subsequent merge-and-re-review at ce87cd4) is 6f18e8d, which adds a single CHANGELOG.adoc/README.adoc entry describing the suite. Confirmed via git diff ce87cd4..6f18e8d: it touches only those two doc files (+1/+1), no chaos-suite code. Nothing new to review functionally.

🔴 Still open (unchanged, 4th time flagged): chaos-pain.yml selects zero tests

.github/workflows/chaos-pain.yml:82 (verified against current HEAD):

-Dincluded.groups=chaos -Dexcluded.groups=quarantined

ChaosChurnStormIT (.../chaostests/ChaosChurnStormIT.java:65,93) is still the only @Tag("chaos") test and is still @Quarantined (→ implicit @Tag("quarantined")). JUnit5/Failsafe applies tag exclusion after inclusion, so this combination selects zero tests on every run — both workflow_dispatch and the per-PR-commit pull_request trigger — and failIfNoTests is unset anywhere in the pom/scripts, so the job reports green having executed nothing.

This has now been raised in four review rounds. It was acknowledged as a deliberate interim tradeoff in commit c3ba4e1 (avoid the known #80-pending RED drowning the tripwire), but the two requested follow-ups are still outstanding:

  1. AGENTS.md:99 / docs/inflight.md:71-72 still document the local recipe (-Dexcluded.groups=, empty) as equivalent to what chaos-pain.yml runs — that's currently false, with no caveat anywhere.
  2. The workflow's own header comment (chaos-pain.yml:12-13, "a RED here is a real finding — the suite is calibrated GREEN on both assignors") is stale, and nothing in the job surfaces "0 tests selected" — it's visually indistinguishable from a real GREEN run in the Checks UI, on a PR whose entire premise is "reds on master today, on first contact."

The newly-added changelog line (CHANGELOG.adoc/README.adoc) reinforces this gap rather than closing it — it describes the suite as running "per same-repo PR commit on the self-hosted highcpu runner," which is accurate about when the job fires but says nothing about it currently selecting zero tests while ChaosChurnStormIT stays quarantined.

Since this is a .github/workflows/* file, I can't push the fix myself (GitHub App permissions block workflow edits) — this needs @astubbs to action, either by dropping -Dexcluded.groups=quarantined (matching bin/quarantined-test.sh / bin/performance-test.sh's convention) or by keeping the exclusion and adding the doc caveat + a visible zero-tests signal (e.g. print selected/executed test count from the failsafe reports, or set failIfNoTests=true).

Fix this →

Everything else

No new issues. All previously-reviewed code (ChaosConductor's deterministic TickDraws model, ProgressProbe's SLO math, the ledger's vacuous-bound cap, ManagedPCInstance's MDC/exception handling, the workflow-input injection fix) is unchanged since the last clean pass and wasn't re-flagged. The one substantive open item across every round remains the zero-test-selection gap above.

…unds 3-5 follow-up

The chaos-pain job deliberately excludes @Quarantined scenarios (decision
in c3ba4e1: the known #80-pending W1 RED must not drown the tripwire
signal), which currently means it selects ZERO tests. The review's two
outstanding asks, now addressed:

- chaos-pain.yml timing summary: prints a loud 'ZERO chaos tests selected
  - this run measured NOTHING' banner (instead of an empty table
  impersonating a real GREEN) when no failsafe reports exist; header
  comment documents the quarantine interaction and the interim window.
- AGENTS.md chaos section + docs/inflight.md: the CI job is no longer
  described as equivalent to the local full recipe - the quarantine
  exclusion and the temporary zero-test state are called out explicitly.

Coverage returns when the W4 variants (#85/#87) or the #80 fix land.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK
@claude

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

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


Code review — PR #83 (Chaos Pain Suite)

Todo list

  • Gather context (PR body, prior review rounds, changed files list)
  • Check out branch and diff since last reviewed commit (6f18e8d)
  • Re-verify the previously-flagged chaos-pain.yml zero-test issue
  • Post review feedback

Summary

One commit landed since the last review round: 816e77c ("docs(chaos): make the zero-test quarantine window visible — review rounds 3-5 follow-up"). It's a direct, correct fix for the one open item this suite has carried across five review rounds.

✅ The zero-test-selection finding (flagged in rounds 1, 3, 4, 5) is now resolved

.github/workflows/chaos-pain.yml:94 still runs -Dincluded.groups=chaos -Dexcluded.groups=quarantined, which still selects zero tests today (ChaosChurnStormIT remains the only @Tag("chaos") scenario and is still @Quarantined pending #80) — but that's now a documented, visible, deliberate state rather than a silent gap:

This is exactly the second of the two options I'd suggested each round ("keep the exclusion deliberately and add the doc caveat + a visible zero-tests signal"), executed cleanly across all three of the places that needed it.

Remaining nit (non-blocking, cosmetic): chaos-pain.yml:11-14's original trigger-comment text — "pull_request ... ambient tripwire (a RED here is a real finding — the suite is calibrated GREEN on both assignors)" — is still worded as if the per-commit run is currently exercising real assertions. It now sits directly above the new, accurate QUARANTINE interaction block (lines 16-20), so a reader gets the correct picture immediately after, but the top block itself wasn't touched and reads slightly stale in isolation. Not worth another round by itself — could be folded in whenever this file is next touched (e.g. when #80 or a W4 variant lands and real coverage returns).

Everything else

No new code changes since the last round (only .github/workflows/chaos-pain.yml, AGENTS.md, docs/inflight.md touched, all doc/CI-visibility only). All previously-reviewed suite code (ChaosConductor's deterministic TickDraws model, ProgressProbe's SLO math, the ledger's vacuous-bound cap, ManagedPCInstance's MDC fix, the workflow-input injection fix) remains unchanged and clean.

No outstanding blocking issues from this review.

@astubbs

astubbs commented Jul 31, 2026

Copy link
Copy Markdown
Owner Author

Review response (re: the recurring zero-tests finding, rounds 3-5) - addressed in 816e77c

The decision stands as the interim tradeoff from c3ba4e1: chaos-pain.yml keeps excluding @Quarantined scenarios so the known #80-pending W1 RED doesn't drown the tripwire signal (the Quarantine Lane owns quarantined tests). The two outstanding follow-ups are now in:

  1. Zero-test state is loudly visible. The timing summary now prints ZERO chaos tests selected - this run measured NOTHING (with the why + pointer to docs/QUARANTINED_TESTS.md) whenever no failsafe reports exist, instead of rendering an empty table indistinguishable from a real GREEN. The workflow header comment documents the quarantine interaction and the interim window.
  2. Docs no longer overclaim. AGENTS.md (chaos section) and docs/inflight.md now state explicitly that the CI job - unlike the local -Dexcluded.groups= recipe - excludes quarantined scenarios, and that it selects zero tests while W1 sits quarantined under PR fix(core): draining PC stops polling - 10kHz busy-spin + zombie partition hold (#857-family silent stall) #80.

Coverage returns automatically when the W4 variants (#85/#87) or the #80 fix land - either adds non-quarantined chaos scenarios back into the job's selection.

Earlier rounds' fixes (workflow input injection via env:, MDC try/finally) were confirmed correct by round 4's re-verification - no action there.

🤖 Generated with Claude Code

https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK

'Temporarily merge the chaos branch into the PR under test' only made
sense while the suite lived on an unmerged branch. Once this PR lands the
suite is on master, so the recipe is: on the fix PR's branch (merge master
in if it predates the suite), run pre-fix vs fix commits and watch
RED->GREEN. Fixed in AGENTS.md + the W1 class javadoc; the PR body is
updated in the same pass.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK
@claude

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

Claude finished @astubbs's task in 50s —— View job


Code review — PR #83 (Chaos Pain Suite)

Todo list

  • Gather context (PR body, prior review rounds, changed files list)
  • Check out branch and inspect diff since last reviewed commit (816e77c)
  • Review new changes
  • Post review feedback

Summary

One commit landed since the last full review round: 5e1f2d8 ("docs(chaos): probe-a-fix-PR recipe updated for post-merge reality"). It's doc-only — no chaos-suite code changed.

The fix corrects a recipe that no longer made sense once this PR is destined to land on master: the old "Probe a fix PR" instructions said to temporarily merge the chaos branch into the PR under test (correct while the suite lived on an unmerged branch), but once the suite is on master, a fix PR that branched after this merges already has the suite — no manual merge-in step is needed. The new recipe is simpler and correct: on the fix PR's branch (merging master in first only if the branch predates the suite landing), run pre-fix vs. fix commits and watch RED→GREEN.

Verified:

  • AGENTS.md:105 and ChaosChurnStormIT.java's class javadoc (lines 55-56) are updated in lockstep — same recipe, same wording, no drift between the two copies.
  • Grepped for the old "temporarily merge... chaos branch" phrasing across .md/.java/.adoc — no stale copies remain (the PR body was already updated to this wording in an earlier pass, per the PR description's "Usage patterns" section, so it's now consistent everywhere).
  • Cross-checked docs/inflight.md and docs/QUARANTINED_TESTS.md — neither restates the old recipe, so nothing else needed updating.

No functional, security, or test-coverage changes in this commit, and no new issues found.

Standing item (informational only, not re-litigated)

The chaos-pain.yml zero-test-selection window (flagged across rounds 1, 3-5, and resolved for visibility in 816e77c) is unaffected by this commit — it remains a deliberate, now well-documented interim state pending #80 or the W4 variants. Nothing new to add here.

@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

…s dispatch-only

Review of today's runner meltdown: independent self-hosted workflows can't
see each other's load, and the per-PR trigger semantics (cancel superseded)
fought chaos-pain's dispatch semantics (queue, never kill). Split cleanly:

- bin/chaos-test.sh: shared runner - the chaos mvn invocation, timing
  summary and the zero-test quarantine banner (emitted on EVERY exit via
  trap, so a RED run still gets its autopsy summary). Inputs via env only.
- pr-highcpu-fast-feedback.yml: new 'Chaos Pain Suite' matrix entry - the
  per-PR ambient tripwire, sharing the lane's same-repo guard and
  per-suite superseding. NOT optional (continue-on-error false, bare check
  name): a chaos RED is a real finding and shows red.
- chaos-pain.yml: workflow_dispatch only (seed/reps hunts), queue-never-
  kill preserved; delegates to bin/chaos-test.sh.
- AGENTS.md / docs/inflight.md / CHANGELOG+README bullet updated.

Verified: bash -n, actionlint both workflows, copyright scan clean.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK
@claude

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

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


Code review — PR #83 (Chaos Pain Suite)

Todo list

  • Gather context (PR body, prior review rounds, changed files list)
  • Check out branch and inspect diff since last reviewed commit (5e1f2d8)
  • Review new changes (effa942: chaos-pain moves to highcpu lane / dispatch-only)
  • Post review feedback

Only one commit landed since the last review round: effa942 ("ci(chaos): per-PR chaos run moves into the highcpu lane; chaos-pain is dispatch-only"). It's a real refactor — it drops chaos-pain.yml's pull_request trigger, adds a Chaos Pain Suite matrix entry to pr-highcpu-fast-feedback.yml (deliberately not continue-on-error, per its own comment: "a chaos RED is a real finding and must show red, not neutral"), and extracts the run logic both workflows share into a new bin/chaos-test.sh. Docs (AGENTS.md, docs/inflight.md, CHANGELOG.adoc, README.adoc) were updated in lockstep and read consistently.

🔴 bin/chaos-test.sh's EXIT trap swallows the real exit code — a chaos failure now reports as CI success

bin/chaos-test.sh:52-56:

emit_summaries() {
    summary || true
    if [ -n "${GITHUB_STEP_SUMMARY:-}" ]; then summary >> "$GITHUB_STEP_SUMMARY" || true; fi
}
trap emit_summaries EXIT

run under set -euo pipefail (line 17), with the actual test run at lines 58-64 (time ./mvnw ... verify ... inside the for loop).

This is the classic bash trap gotcha: emit_summaries never captures $? before running its own commands, and every command inside it is deliberately made to succeed (|| true, or an if with no else, which itself returns 0 when the condition is false). When errexit fires because mvnw verify fails (a real chaos RED — exactly the case this design is supposed to surface), bash records the pending non‑zero status, runs the EXIT trap, and then — because the trap doesn't call exit with a captured code — uses the trap's own last command's exit status as the script's final exit status. That's unconditionally 0. Net effect: bin/chaos-test.sh exits 0 regardless of whether mvnw verify passed or failed, which means both call sites report green on a real failure:

  • The new highcpu / Chaos Pain Suite step in pr-highcpu-fast-feedback.yml (not continue-on-error, meant to show red on a real finding) — will just show green.
  • The on-demand chaos-pain.yml dispatch workflow — same.

You can confirm the underlying bash behavior with a two-line repro: bash -c 'set -e; trap "true" EXIT; false'; echo $? prints 0, not 1. (This is why the idiomatic fix is to capture $? as the trap's first statement and re-exit with it explicitly.)

This is a regression introduced by this exact commit: the previous design (removed by this diff) ran the mvnw command and the summary as two separate GitHub Actions steps (Chaos runs + Timing summary, the latter if: always()), so the first step's exit code was never touched by the second — failures propagated correctly. Consolidating both into one script via a trap ... EXIT reintroduced exactly the "reports green having failed/found nothing" pattern that took five review rounds to stamp out of the old chaos-pain.yml, except this time it masks an actual RED, not just a zero-test selection.

Fix: capture and re-raise the exit code explicitly:

emit_summaries() {
    local ec=$?
    summary || true
    if [ -n "${GITHUB_STEP_SUMMARY:-}" ]; then summary >> "$GITHUB_STEP_SUMMARY" || true; fi
    exit "$ec"
}
trap emit_summaries EXIT

Fix this →

Minor / informational (not blocking)

  • CHANGELOG.adoc:25 still describes the whole pr-highcpu-fast-feedback.yml lane in blanket terms as continue-on-error + not required — that's no longer true of the new Chaos Pain Suite matrix entry specifically (pr-highcpu-fast-feedback.yml:56, continue-on-error: ${{ matrix.optional != 'false' }}), though it's still true that it isn't a required gate. Pre-existing line, not touched by this commit — worth a pass whenever that changelog entry is next touched, not urgent.
  • Making the "Chaos Pain Suite" step non-continue-on-error on a self-hosted runner reintroduces, for that one entry, the "offline runner blocks/red-flags an unrelated check" risk that continue-on-error: true was originally added lane-wide to avoid (per CHANGELOG.adoc:25's own rationale). Since it's still an optional/non-required check per the if: guard and naming, this looks like a deliberate, reasoned tradeoff (visibility for real REDs vs. false-red on infra hiccups) rather than an oversight — just flagging for awareness in case it wasn't consciously weighed against that original rationale.

Everything else

The matrix name/continue-on-error expression logic (pr-highcpu-fast-feedback.yml:46,56,88-95) is sound — verified both branches (matrix.optional unset vs "false") evaluate as intended. The chaos-pain.yml trim-down (removing the pull_request trigger, same-repo guard, and the now-shared script) is a clean, correct extraction with no logic drift from what round 5 approved, aside from the trap bug above which lives entirely in the newly-added bin/chaos-test.sh. Docs (AGENTS.md:98-109, docs/inflight.md:69-75) accurately describe the new split between the per-PR highcpu lane and the on-demand dispatch workflow.

… reported green

Review round 6 caught a real regression from effa942: an EXIT trap's own
last command becomes the script's exit status, and everything in
emit_summaries is made to succeed - so bin/chaos-test.sh exited 0 even
when mvnw verify failed, turning a real chaos RED green at both call
sites (the non-optional highcpu lane entry included). Exactly the
silent-success pattern five prior rounds stamped out.

Fix: capture $? first, re-exit with it after emitting summaries.
Verified with stub harness: failing run propagates exit 1 (banner still
emitted), passing run exits 0.

Also: CHANGELOG/README no longer describe the highcpu lane as blanket
continue-on-error - the Chaos Pain Suite entry is deliberately not
(round-6 minor note).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK
@astubbs

astubbs commented Jul 31, 2026

Copy link
Copy Markdown
Owner Author

Review response (round 6) - trap bug fixed in b35d46b

The EXIT-trap exit-code swallow: confirmed real, fixed. Textbook version of exactly what the review said - the trap's own always-succeeding last command became the script's exit status, so a genuine chaos RED reported green at both call sites. emit_summaries now captures $? first and re-exits with it after emitting the summaries. Verified with a stub harness (mvnw replaced by false/true): failing run propagates exit 1 with the banner still emitted, passing run exits 0. Painful irony acknowledged: the refactor that consolidated the summary steps reintroduced the silent-green class this PR spent five rounds eliminating - good catch.

Minor note also taken: CHANGELOG/README no longer describe the lane as blanket continue-on-error; the Chaos Pain Suite entry's exception (deliberately loud RED, still not a required gate) is called out.

The offline-runner tradeoff flag: consciously weighed, keeping as-is - a pending/red chaos check from an offline runner is acceptable noise for an unmissable tripwire, and it stays out of the required set precisely so it can never block a merge.

🤖 Generated with Claude Code

https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK

@claude

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

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


Code review — PR #83 (Chaos Pain Suite)

Todo list

  • Gather context (diff since last reviewed commit)
  • Review new changes (b35d46b: EXIT-trap fix)
  • Post review feedback

Summary

One commit landed since the last review round: b35d46b ("fix(chaos): EXIT trap must re-raise the run's exit code — a chaos RED reported green"), addressing the exit-code-swallowing bug flagged in round 6.

✅ The EXIT-trap bug is correctly fixed

bin/chaos-test.sh:56-61:

emit_summaries() {
    local ec=$?
    summary || true
    if [ -n "${GITHUB_STEP_SUMMARY:-}" ]; then summary >> "$GITHUB_STEP_SUMMARY" || true; fi
    exit "$ec"
}
trap emit_summaries EXIT

This is the correct idiom: local ec=$? as the trap's first statement captures the triggering exit status before anything else runs (including local itself, which doesn't clobber $? until after the assignment's command substitution — here there's none, so the plain $? read happens first), and the explicit exit "$ec" at the end makes that captured code the script's real exit status regardless of what the summary commands (deliberately || true'd) return. This closes the exact failure mode from round 6 — under set -e, mvnw verify failing in the loop (lines 64-70) now correctly propagates through the trap instead of being masked by the trap's own always-0 last command. The inline comment (lines 52-55) documents the bug and repro clearly for future maintainers.

I traced the logic by hand rather than executing it live (sandboxed shell execution in this environment required approvals I didn't have for this pass), but the pattern matches the well-established fix for this exact bash gotcha and the code reads correctly against both the failing and passing paths.

The accompanying CHANGELOG.adoc/README.adoc edits correctly scope the continue-on-error caveat to just the Chaos Pain Suite matrix entry rather than the whole highcpu lane, closing the round-6 minor note as well.

No new issues found

Nothing else changed in this commit. All previously-reviewed code and CI wiring remain unchanged since the last clean passes. This closes out the last open finding from the review series — no outstanding blocking issues.

astubbs added a commit that referenced this pull request Jul 31, 2026
…work - head start on #83 landing

Non-trivial resolutions (base evolved past what this branch extracted):
- ChaosScenarioBase helpers upgraded to base's new W1 epilogue semantics:
  settleFleet waits out stopAsync close-pending, settleRun takes/kills the
  pcExecutor, assertScenarioSlos uses the full replay command in messages,
  adds the unclassified-failure-cause canary sweep, and uses
  conductor.getDisturbanceCount()
- W1 keeps its slim helper-calling body + base's @Quarantined + replayCmd
- W4 adopts the same replayCmd pattern for message parity
- W4 plan tests ported from removed planActions to planTicks/TickDraws
  (base's single-draw-path rework); ChaosConductorPlanIT 4/4 green
- ManagedPCInstance: extraConsumerProps merge re-seated in base's
  restructured run(); Config field unchanged
- AGENTS.md: dropped this branch's chaos signpost bullet (base now has a
  full Chaos Pain Suite section); added W4 + ChaosScenarioBase to it
- inflight.md: chaos Phase 2+ roster kept, updated to post-merge reality
  (cooperative lever -> PR #87, ambient probe -> PR #86); dropped the
  fork-header roster entry (base's copyright work already flipped them)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018igSVt74wPQAbRNHkXS4R8
…dencies'

Two fixes for the newly-required check:
- synchronize added to the trigger types: required checks are evaluated
  per head SHA, and without it a plain push produced no run - the check
  sat 'Expected - waiting for status' forever, blocking merges.
- Job renamed 'Check Dependencies' -> 'Check PR Dependencies' (clearer:
  it gates stacked-PR 'depends on #N' ordering, not library dependencies).
  Ruleset context updated to match.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ALhTf1TRA2S6Ue5rkiQdK
@claude

claude Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

Claude finished @astubbs's task in 42s —— View job


Code review — PR #83 (Chaos Pain Suite)

Todo list

  • Gather context (PR body, prior review rounds, changed files list)
  • Check out branch and inspect diff since last reviewed commit (b35d46b)
  • Review new changes (8504817: PR dependency gate synchronize fix)
  • Post review feedback

Summary

One commit landed since the last review round: 8504817 ("fix(ci): PR dependency gate runs on push + renamed to 'Check PR Dependencies'"). It touches only .github/workflows/check-dependencies.yml (+6/-2) — no chaos-suite code changed.

✅ Clean, well-justified fix

 on:
   pull_request:
-    types: [opened, edited, closed, reopened]
+    types: [opened, edited, closed, reopened, synchronize]

This closes a real GitHub Actions gotcha: once a workflow is configured as a required status check, required checks are evaluated per head SHA. Without synchronize in the pull_request trigger's types, no new run is created when a new commit is pushed to the PR branch — the check just sits "Expected — waiting for status" against the new SHA forever, permanently blocking merge regardless of the underlying dependency state. The inline comment (lines 3-6) documents this precisely, including that it was discovered by this PR being bitten by it (consistent with this being the required "PR Dependency Check" referenced in the PR body's depends on #75).

The accompanying rename (Check Dependencies → Check PR Dependencies) is presumably to keep the job's display name in sync with whatever name is now configured as the required check in branch protection — can't verify the branch-protection config from here, but the rename itself introduces no risk on its own (GitHub creates a new check run under the new name; any status-check requirement referencing the old name would need updating in branch protection settings, which is outside this diff's scope but worth confirming was also done).

No functional issues found. This is a workflow file, so I can't push a fix myself even if one were needed — not applicable here since there's nothing to fix.

Everything else

Unchanged since the last clean pass (round 7, b35d46b): the deterministic ChaosConductor/ProgressProbe suite code, the ledger's vacuous-bound cap, ManagedPCInstance's MDC/exception handling, the bin/chaos-test.sh EXIT-trap fix, and the highcpu-lane/dispatch-only CI split. No outstanding blocking issues across the full review series.

@astubbs
astubbs merged commit 9ccf2ec into master Jul 31, 2026
27 of 29 checks passed
@astubbs
astubbs deleted the feats/chaos-pain-suite branch July 31, 2026 04:34
astubbs added a commit that referenced this pull request Jul 31, 2026
…s pre-diagnosed (#86)

AmbientProbeExtension (JUnit 5, on BrokerIntegrationTest - all ~104 broker ITs
inherit it) runs the chaos suite's ProgressProbe in a new observer mode under
every test: rebalance-dwell + per-partition committed-offset lag stagnation,
sampled purely from admin-client reads. On test failure it logs an autopsy
block (violations, peaks, frozen-partitions table) so a generic Awaitility
timeout arrives pre-diagnosed: "zombie member blocked rebalance 15s" vs
"partition 21 committed frozen lag=1132" vs "probe clean - fault is likely in
the test itself". Observer mode never fails a test; silent on green (DEBUG
one-liner). Escape hatches: -Dambient.probe=off, @NoAmbientProbe.

ProgressProbe: explicit Mode enum (CHAOS / AMBIENT_OBSERVER), group id via
Supplier (follows NEW_GROUP switches), watermark maps re-keyed
Integer -> TopicPartition (fixes a latent cross-topic collision), observer
violations recorded but logged DEBUG. Chaos-mode behavior unchanged; #85's
per-scenario toggles carried through intact.

Lifecycle hardening: sampler stops in AfterTestExecutionCallback (before
@AfterEach closes the admin client; verified against the pinned
junit-jupiter-engine bytecode), afterEach as idempotent safety net;
KafkaClientUtils.close() nulls the volatile admin field in a finally, samplers
use the lifecycle-safe adminIfOpen() Optional accessor.

Tests: AmbientProbeExtensionTest (14 broker-free unit tests) - isDisabled()
opt-out matrix, autopsy formatting branches, beforeEach fallbacks, stop()
idempotence, observer/chaos log-level contract. Docs: AGENTS.md points
test-debuggers at the autopsy first; docs/inflight.md shrunk per its scope
rule (#83/#85 entries retired).

Verified: real autopsy produced on a W1 chaos failure with chaos probe
behavior bit-identical; zero ambient output on green runs; unit suite
311/0 attributable; clean automatic review of the final head.
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