Skip to content

[improve][ci] Enforce nightly chaos fault regressions - #27044

Draft
codelipenghui wants to merge 1 commit into
apache:masterfrom
codelipenghui:ci/nightly-chaos-regressions
Draft

codelipenghui wants to merge 1 commit into
apache:masterfrom
codelipenghui:ci/nightly-chaos-regressions

Conversation

@codelipenghui

Copy link
Copy Markdown
Contributor

Motivation

Existing performance-framework fault scenarios were not run in CI, and the real network-injection checks were excluded from ordinary launcher tests. The deduplication correctness test covering BookKeeper failures was also disabled because its unbounded workload could exhaust memory, leaving that regression in quarantine.

Make a small set of existing fault scenarios fail-on-error CI checks, and restore bounded deduplication failure coverage in the normal broker client API test group.

Modifications

  • Add a five-scenario matrix to the JDK 21 nightly Pulsar CI schedule and manual workflow runs: broker isolation, metadata takeover, bookie partition, silent client disconnection, and geo partition.
  • Add a small CI telemetry scenario with fixed workload bounds, retaining the existing overlays' fault timings and failover quorums. Disable metrics and perf-event collection for these correctness runs.
  • Require the real networkCheck on relevant launcher, loader, scenario, test-image, and CI wiring changes, as well as nightly/manual runs.
  • Connect both jobs to the existing required Pulsar CI checks completed gate. Selected jobs must succeed; failures, cancellations, and unexpected skips are not accepted.
  • Retain fault-run outputs and container logs for seven days, including partial outputs on failure. Retain failed network-check artifacts alongside test reports.
  • Replace the disabled, unbounded deduplication correctness test with ClientDeduplicationRecoveryTest in the normal broker-api group. It uses a private real BookKeeper ensemble, at most eight outstanding sends, 33 total send attempts, finite timeouts, an observed storage write failure, duplicate replay after recovery, and exact persisted sequence/completion assertions. Leave the unrelated legacy failure test quarantined.
  • Extend scenario-resolution tests to cover the CI workload and fault overlays, and document the suite and local reproduction commands.

The performance fault suite retains the framework's at-least-once delivery contract: consumer duplicates alone do not fail a run. It does not establish performance baselines or a recovery-time SLA.

Verifying this change

  • Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

  • Passed: ./gradlew quickCheck --max-workers=2 (license headers and source style across modules).
  • Passed: performance framework unit tests in common, tools, launcher, report-tool, and metrics, using --tests '*Test', one test fork, and -PtestRetryCount=0.
  • Passed: ClientDeduplicationRecoveryTest in three separate runs with retries disabled, including two runs explicitly selecting -PtestGroups=broker-api. Each run executed the regression without skips.
  • Passed: workflow/filter YAML parsing, shell syntax checks for the new job commands, required-gate wiring checks, and git diff --check.
  • Failed locally: :tests:performance:launcher:networkCheck stopped at the existing capability probe with ss -K destroyed no TCP socket on Docker Desktop (LinuxKit 7.0.14). A separate disposable network namespace reproduced zero destroyed sockets even with established connections. The capability failure remains fail-closed; no checks were weakened or skipped to obtain a pass.
  • Not run: the five end-to-end nightly fault scenarios and the GitHub Actions workflow. Supported Linux-runner validation remains outstanding; this PR is a draft for that reason.

Does this pull request potentially affect one of the following parts:

  • Dependencies (add or upgrade a dependency)
  • The public API
  • The schema
  • The default values of configurations
  • The threading model
  • The binary protocol
  • The REST endpoints
  • The admin CLI options
  • The metrics
  • Anything that affects deployment

Run bounded nightly fault scenarios through the required CI gate, validate real injection on framework changes, retain failure artifacts, and restore a bounded deduplication recovery regression outside quarantine.

Assisted-by: DeepSeek Harness (gpt-6.1-sol)

@lhotari lhotari left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Great idea! I added some comments, mainly about adding a new workflow file such as pulsar-performance.yaml for the workflow changes.

Comment on lines +97 to +103
performance_network: >-
${{ steps.changes.outputs.performance_network == 'true'
|| github.event_name == 'workflow_dispatch'
|| (github.event_name == 'schedule' && github.event.schedule == '0 6 * * *') }}
performance_faults: >-
${{ github.event_name == 'workflow_dispatch'
|| (github.event_name == 'schedule' && github.event.schedule == '0 6 * * *') }}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think that it would be better to have a separate workflow file for these. It would allow adding more scenarios to be triggered manually (workflow_dispatch) with a selection or with scheduling.


// TODO: Test disabled since it results in a OOME
@Test(timeOut = 300000, groups = "quarantine", enabled = false)
public void testClientDeduplicationCorrectnessWithFailure() throws Exception {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

would it make sense to split this change to a separate PR?

* Uses a private real BookKeeper ensemble: stopping every bookie must not affect the shared test cluster.
*/
@Test(groups = "broker-api")
public class ClientDeduplicationRecoveryTest extends BkEnsemblesTestBase {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

separate PR?

with:
action: wait

performance-network-check:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

please make changes to a separate workflow file such as pulsar-performance.yaml etc.

The workflow can be simplified since with Gradle, there's no need for separate build steps for the docker container and so on. A single job with multiple sequential steps could handle the tests to begin with. Later on it could be parallelized if the build time grows too much.

@lhotari

lhotari commented Oct 22, 2026

Copy link
Copy Markdown
Member
  • Add a five-scenario matrix to the JDK 21 nightly Pulsar CI schedule and manual workflow runs: broker isolation, metadata takeover, bookie partition, silent client disconnection, and geo partition.

Since Java 25 is the default for Pulsar deployments, it's worth testing with Java 25 in the separate workflow. There could be a selection to choose Java 21 in the manual trigger (workflow_dispatch).

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.

2 participants