Skip to content

QUEUE-149: Strengthen read-only appender rejection test - #1757

Merged
peter-lawrey merged 1 commit into
developfrom
test/read-only-appender-rejection
Sep 8, 2026
Merged

peter-lawrey merged 1 commit into
developfrom
test/read-only-appender-rejection

Conversation

@peter-lawrey

@peter-lawrey peter-lawrey commented Sep 8, 2026

Copy link
Copy Markdown
Member

Purpose

Extract the read-only test-quality improvement from #1702 without importing the bulk JUnit 5 migration.

The old whole-method expected exception could pass when opening the queue failed. Its Windows branch manufactured the expected exception and reported a pass without testing rejection.

Change

One method in one file, based on develop d1cc3c87a04539ee1d3aedb7696f39bc2261f68e:

  • Report the unsupported Windows path as an assumption skip.
  • Build the read-only queue outside the expected-rejection scope.
  • Catch IllegalStateException only from createAppender().
  • Fail if acquisition returns. Close any unexpectedly returned appender using try-with-resources; a close failure is suppressed on the assertion failure, not accepted as rejection.

JUnit 4, the inherited timeout and lifecycle, public test visibility, the test JAR, POMs and production sources remain unchanged. This is preparatory strengthening, not a claim that Jupiter migration is complete. #1702's shared-fixture migration still needs independent review.

Validation

Executed locally on Linux x86_64, Maven 3.9.11; these are local results, not an attestation of remote CI:

Check Result
Java 21.0.12: mvn -B -ntp clean verify -l <log> at 6b19d66dc4389e61660ddbd3f57a8075e975f5b5 1,114 tests reported; zero failures/errors; 52 skipped
mvn -B -ntp -Dtest=ReadWriteTest test -l <log> Six tests passed on both Java 21.0.12 and Java 8u502
Compatibility enforcer against 2026.0 100% binary and source; production-library report only
javap -public comparison of ReadWriteTest Public signatures unchanged

Also executed ten derived before/after copies of the actual test through JUnit 4 and the unchanged shared fixture. Controlled queue/appender proxies were substituted only in the target method; real setup/teardown still ran:

Injected condition Old test New test
Appender acquisition rejects Pass Pass
Queue opening throws False pass Fails
Acquisition returns; close succeeds Fails Fails; appender closed once
Acquisition returns; close throws False pass Assertion fails; close exception retained as suppressed; closed once
Windows branch selected Manufactured pass Assumption skip

The Windows row is a controlled branch probe on Linux, not native Windows execution. No production classes were modified or runtime bug claimed. Full-suite skips include unavailable huge-page coverage; platform CI remains a separate check.

Run receipt and resolved snapshot identities

Full verification log excerpt:

Tests run: 1114, Failures: 0, Errors: 0, Skipped: 52
BINARY COMPATIBILITY ENFORCER - SUCCESSFUL - chronicle-queue
BUILD SUCCESS
Total time: 02:49 min
Finished at: 2026-09-08T06:55:14+01:00

Selected resolved dependencies: Core 2026.6, Bytes 2026.4, Wire 2026.10-SNAPSHOT, Threads 2026.3; JUnit 4.13.2 and Vintage 5.10.0. Parent and third-party BOM remain 2026.0; Chronicle BOM remains 2026.0-SNAPSHOT.

SHA-256 of the actual local snapshot inputs:

  • Chronicle BOM POM: 5e9ce529e8aaa9f9930658b2ef59222ebffe164fb8e6d31ce0b4e204cb1d55a0.
  • Wire JAR: 77afd5d4236c738c25980c268858879b6c929e70486b829b5e4a434dd6b31c87.

Both were locally installed snapshots; no remote timestamped identity is claimed. XML reports were archived separately before later test runs could overwrite them. Existing expected read-only fallback logs and shaded-resource warnings remain; this is not a warning-free build claim.

CI status snapshot (2026-09-08 06:19 UTC)

Exact-head statuses: seven successful, one failed (Zing 11), four pending. The failed Zing 11 job remains uninvestigated: the unauthenticated TeamCity guest REST request returned HTTP 401. The cause is not attributed to this patch, the baseline or infrastructure. Local successful verification does not resolve that CI failure.

Extract the useful assertion-scope improvement from #1702 on current develop.

Opening a queue or closing an unexpectedly returned appender must not
satisfy the expected acquisition failure. Catch only acquisition rejection,
fail before closing an unexpected appender, and report unsupported Windows
execution as a skip. Preserve JUnit 4 lifecycle, timeouts and public tests.

Focused ReadWriteTest run: 6 tests, no failures, errors or skips on Linux
Java 21. Full verification and fault-injection evidence follow before PR.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟢 Approval recommended

The reviewed test change is focused and has no unresolved issues.

Pull request overview

Strengthens the JUnit 4 read-only appender test to prevent false positives.

Changes:

  • Skips unsupported Windows execution.
  • Limits expected rejection to createAppender().
  • Closes unexpectedly returned appenders safely.
File summaries
File Description
src/test/java/net/openhft/chronicle/queue/ReadWriteTest.java Hardens read-only appender rejection testing.
Review details
  • Files reviewed: 1/1 changed files
  • Comments generated: 0
  • Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@peter-lawrey peter-lawrey changed the title Strengthen read-only appender rejection test QUEUE-149: Strengthen read-only appender rejection test Sep 8, 2026
@peter-lawrey peter-lawrey self-assigned this Sep 8, 2026
@peter-lawrey
peter-lawrey merged commit 5dcc5c9 into develop Sep 8, 2026
11 of 13 checks passed
@peter-lawrey
peter-lawrey deleted the test/read-only-appender-rejection branch September 8, 2026 13:06
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.

3 participants