Skip to content

Add spring-core regression test for gh-37159 SubscriberInputStream interrupt fix - #2

Draft
jaipilot[bot] wants to merge 1 commit into
jaipilot-demo/spring-37159from
jaipilot/pr-1-HBUB1UGBVTRD
Draft

Add spring-core regression test for gh-37159 SubscriberInputStream interrupt fix#2
jaipilot[bot] wants to merge 1 commit into
jaipilot-demo/spring-37159from
jaipilot/pr-1-HBUB1UGBVTRD

Conversation

@jaipilot

@jaipilot jaipilot Bot commented Aug 22, 2026

Copy link
Copy Markdown

Context: This is a JAIPilot Cloud companion evaluated against skrcode/spring-framework PR #1, an exact mirror of spring-projects#37159 ("Fix busy-spin in SubscriberInputStream await()"). The base commit already contains the production fix in both near-duplicate classes: spring-core/.../io/buffer/SubscriberInputStream and spring-web/.../http/client/SubscriberInputStream.

What changed: Added inputStreamSubscriberInterruptWhileAwaitingData() to spring-core's DataBufferUtilsTests, testing the same interrupt-while-parked contract that spring-web's SubscriberInputStreamTests.interruptWhileAwaitingData() already covers, but through spring-core's public DataBufferUtils.subscriberInputStream(Publisher, int) entry point. No production code was modified.

Why: The original PR fixed the identical bug in two independently-maintained near-duplicate classes but only added a regression test for one of them (spring-web). The spring-core copy — used internally by the public DataBufferUtils.subscriberInputStream API — had zero prior test coverage for this scenario, leaving the busy-spin/interrupt fix unverified on that path.

Behavior preserved: The reader thread parks (Thread.State.WAITING) while awaiting data; on interruption, read() throws InterruptedIOException("Interrupted while awaiting data"), the thread terminates promptly, and the interrupt status is restored on the caller — identical contract to the already-tested spring-web class.

Cleanup / performance / modernization: Evaluated and found already satisfied or not applicable — see the measurements.passes detail for the specific hypotheses considered (duplicate catch-block extraction, the required extra volatile read in await()) and why each was rejected as unsafe or of no proven benefit within this bounded scope. No build, dependency, or JDK path was touched by the original PR, so modernization is out of scope.

Verification: behavior_baseline and behavior_candidate use the identical focused Gradle command and both pass (402 spring-core + 6 spring-web tests, 0 failures). full_build (:spring-core:check :spring-web:check) passes with 9057 tests across both modules, 0 failures/errors.

Limitations: No JMH/microbenchmark evidence was produced for the busy-spin fix itself (it is the original PR's own change, not this companion's); the deterministic Thread.State.WAITING observation in both tests is used as evidence that the fix is effective, per the performance-mode guidance preferring deterministic operation-count-style evidence over noisy timing for this kind of scheduling fix.


Generated by JAIPilot Cloud for #1 from Anthropic session sesn_0157PGf51tDeHBUB1UGBVTRD.

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.

0 participants