chore(deps): bump OpenSearch to 3.7.0#24
Merged
Conversation
Implement proper JSON parsing in HttpNodesStatsAction for the five NodeStats fields added in OpenSearch 3.7.0: - Parse the "native_memory" section (always present in 3.7.0): total_estimated_bytes, analytics_backend (AnalyticsBackendNativeMemoryStats), and native_allocator (NativeAllocatorPoolStats with root and per-pool stats). - Support file cache detailed mode: append detailed=true to the request URL when NodesStatsRequest.isFileCacheDetailed() is set, and parse the resulting "file_cache" (fileCacheOnlyStats) and "block_cache" (BlockCacheStats) sections. - Fix a pre-existing dispatch bug: fileCacheStats is emitted under the "aggregate_file_cache" key (since 3.6.0), not "file_cache", so it was never parsed before. When a section is absent (OpenSearch 1.x/2.x, Elasticsearch 7/8, or pre-3.7 servers) all values keep their previous defaults (null/-1L). Verified with OpenSearch3ClientTest and OpenSearch2ClientTest (110 tests, 0 failures) against real containers.
Cover the parsing added for the five NodeStats fields new in 3.7.0: - parseNativeAllocatorPoolStats, parseAnalyticsBackendNativeMemoryStats, and parseBlockCacheStats helpers (full parse, empty objects, and fields the server does not emit remaining 0) - parseNodeStats dispatch: native_memory (full/minimal/absent/empty, unknown nested object skipped), aggregate_file_cache populating fileCacheStats (regression test for the dispatch fix), detailed file_cache populating fileCacheOnlyStats, and block_cache - defaults preserved (null / -1L) when sections are absent, matching OpenSearch 1.x/2.x and Elasticsearch responses - all new sections combined with existing ones in a single response to guard against parser-position bugs - getCurlRequest appending detailed=true only when NodesStatsRequest.isFileCacheDetailed() is set 79 tests in HttpNodesStatsActionTest, no Docker required.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Upgrade the OpenSearch dependency from 3.6.0 to 3.7.0, following the OpenSearch 3.7.0 release, bump the project version accordingly, and implement proper parsing for the node stats added in 3.7.0.
Changes Made
opensearch.versioninpom.xmlfrom 3.6.0 to 3.7.0OpenSearch3ClientTestfrom 3.5.0 to 3.7.0 (public.ecr.aws/opensearchproject/opensearch:3.7.0)HttpNodesStatsActionfor the fiveNodeStatsfields added in the OpenSearch 3.7.0 API (instead of passingnull):native_memorysection (always present in 3.7.0 responses):total_estimated_bytes→totalEstimatedNativeBytes,analytics_backend→AnalyticsBackendNativeMemoryStats, andnative_allocator(root + per-pool stats) →NativeAllocatorPoolStatsNodesStatsRequest.isFileCacheDetailed()(new in 3.7.0) is set, appenddetailed=trueto the request URL and parse the resultingfile_cache(fileCacheOnlyStats) andblock_cache(BlockCacheStats) sectionsnull/-1L, the sentinel OpenSearch itself uses)fileCacheStatsis emitted under theaggregate_file_cachekey (since 3.6.0), notfile_cache, so it was silently skipped before; it is now parsed correctlyTesting
org.opensearch:opensearch:3.7.0, log4j 2.25.4, and the OpenSearch 3.7.0 image (ECR Public) are all availablemvn clean test-compilepasses against 3.7.0HttpNodesStatsActionTest(79 total, no Docker required) covering the new parsers (native_memory,aggregate_file_cache, detailedfile_cache,block_cache), default preservation when sections are absent, unknown-field robustness, and thedetailed=truequery parameterOpenSearch3ClientTest(73 tests) andOpenSearch2ClientTest(37 tests) — 110 tests, 0 failures, confirming both the new parsing on 3.7.0 and no regression on 2.xBreaking Changes
Additional Notes
BlockCacheStatsreconstruction is partial by design: the server'stoXContentdoes not emithitBytes,missBytes, eviction/removal counts, or the memory/disk usage split, so those record components are set to 0 (the combinedused_in_bytesis assigned tomemoryBytesUsedso re-serialization reproduces the same JSON value)