When I build and run all unit tests locally I get a single failure:
downloadDictionaryCompressionTest_WebSocket_Rwf in Java/Eta/ValueAdd/src/test/java/com/refinitiv/eta/valueadd/reactor/ReactorWatchlistJUnitNew.java fails on current master.
Reported failure
java.lang.AssertionError: expected:<0> but was:<4>
at TestReactor.dispatch(TestReactor.java:352)
at TestReactor.dispatch(TestReactor.java:209)
at TestReactorComponent.closeSession(TestReactorComponent.java:318)
at TestReactorComponent.closeSession(TestReactorComponent.java:310)
at ReactorWatchlistJUnitNew.downloadDataDictionaryCompressionTest(ReactorWatchlistJUnitNew.java:22279)
at ReactorWatchlistJUnitNew.downloadDictionaryCompressionTest_WebSocket_Rwf(ReactorWatchlistJUnitNew.java:22131)
Probably Root Cause
This is a secondary exception masking the real one. downloadDataDictionaryCompressionTest's multi-fragment encode loop repeatedly calls dictionaryRefresh.encode(eIter) against a fixed MAX_ENUM_TYPE_DICTIONARY_MSG_SIZE (12800-byte) buffer. It returns CodecReturnCodes.DICT_PART_ENCODED (more parts remain) for 5 iterations, then on the 6th iteration returns CodecReturnCodes.BUFFER_TOO_SMALL (-21). This throws an AssertionError at the assertTrue(ret >= CodecReturnCodes.SUCCESS) check inside the try block.
Because the test uses a plain try { ... } finally { closeSession(...); tearDownConsumerAndProvider(...); } (not try-with-resources), the finally block's own exception replaces the original one. closeSession() calls consumer.testReactor().dispatch(0, ...), which asserts the consumer's event queue is empty but 4 dictionary-refresh fragments already arrived on the wire and were never drained. This second assertion failure (expected:<0> but was:<4>) is what gets reported, masking the real BUFFER_TOO_SMALL failure.
Confirmed via targeted debug instrumentation of the loop:
DEBUG iter numOfMessages=0 encode ret=10
DEBUG iter numOfMessages=1 encode ret=10
DEBUG iter numOfMessages=2 encode ret=10
DEBUG iter numOfMessages=3 encode ret=10
DEBUG iter numOfMessages=4 encode ret=10
DEBUG iter numOfMessages=5 encode ret=-21 <- BUFFER_TOO_SMALL
Notes
- The structurally identical Socket variant of this test, downloadDictionaryCompressionTest_ZLIB_Socket, was already disabled (//@test) in commit a780de4 ("RTSDK-1555 Fix unit test failures", 2025-07-11). This WebSocket variant appears to have been missed by that same cleanup and left active??
When I build and run all unit tests locally I get a single failure:
downloadDictionaryCompressionTest_WebSocket_Rwf in Java/Eta/ValueAdd/src/test/java/com/refinitiv/eta/valueadd/reactor/ReactorWatchlistJUnitNew.java fails on current master.
Reported failure
java.lang.AssertionError: expected:<0> but was:<4>
at TestReactor.dispatch(TestReactor.java:352)
at TestReactor.dispatch(TestReactor.java:209)
at TestReactorComponent.closeSession(TestReactorComponent.java:318)
at TestReactorComponent.closeSession(TestReactorComponent.java:310)
at ReactorWatchlistJUnitNew.downloadDataDictionaryCompressionTest(ReactorWatchlistJUnitNew.java:22279)
at ReactorWatchlistJUnitNew.downloadDictionaryCompressionTest_WebSocket_Rwf(ReactorWatchlistJUnitNew.java:22131)
Probably Root Cause
This is a secondary exception masking the real one. downloadDataDictionaryCompressionTest's multi-fragment encode loop repeatedly calls dictionaryRefresh.encode(eIter) against a fixed MAX_ENUM_TYPE_DICTIONARY_MSG_SIZE (12800-byte) buffer. It returns CodecReturnCodes.DICT_PART_ENCODED (more parts remain) for 5 iterations, then on the 6th iteration returns CodecReturnCodes.BUFFER_TOO_SMALL (-21). This throws an AssertionError at the assertTrue(ret >= CodecReturnCodes.SUCCESS) check inside the try block.
Because the test uses a plain try { ... } finally { closeSession(...); tearDownConsumerAndProvider(...); } (not try-with-resources), the finally block's own exception replaces the original one. closeSession() calls consumer.testReactor().dispatch(0, ...), which asserts the consumer's event queue is empty but 4 dictionary-refresh fragments already arrived on the wire and were never drained. This second assertion failure (expected:<0> but was:<4>) is what gets reported, masking the real BUFFER_TOO_SMALL failure.
Confirmed via targeted debug instrumentation of the loop:
DEBUG iter numOfMessages=0 encode ret=10
DEBUG iter numOfMessages=1 encode ret=10
DEBUG iter numOfMessages=2 encode ret=10
DEBUG iter numOfMessages=3 encode ret=10
DEBUG iter numOfMessages=4 encode ret=10
DEBUG iter numOfMessages=5 encode ret=-21 <- BUFFER_TOO_SMALL
Notes