feat: complete multi-version protocol via field version registry #1614
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.
Complete the multi-version protocol task from previous PR by implementing the core field version registry mechanism with FieldVersionInitializer.
Core Innovation - Field Version Registry
1. FieldVersionInitializer (NEW - Key Component)
•
executeTimeOut,isAlarm,capacityAlarm→"2.0.0"2. FieldVersionRegistry (NEW)
fieldName → introducedVersionConcurrentHashMapimplementationputIfAbsentensures earliest version wins3. IncrementalContentUtil (Enhanced)
clientVersion >= fieldVersionHow It Works
Server Startup:
FieldVersionInitializer registers known fields to FieldVersionRegistry
Example:
registerField("executeTimeOut", "2.0.0")Client Request (e.g., Client 1.5.0):
→
IncrementalContentUtil.getVersionedContent(param, "1.5.0")→
resolveFieldRules()queriesFieldVersionRegistry→
executeTimeOutrequires"2.0.0"but client is"1.5.0"→ Field filtered out → No invalid refresh ✅
Config Update:
→
CacheItem.clearVersionMd5()clears cache→
getMd5()returns null (FIXED: was returning full MD5)→ Triggers recalculation with correct version filtering
Critical Fixes
FieldVersionInitializer - The Missing Piece
• Previous PR lacked centralized field version management
• Fields were hardcoded or version-unaware
• Now: All extension fields explicitly registered with versions
Cache Refresh Bug (Production Critical)
•
CacheItem.getMd5():getOrDefault(key, fullMd5)→get(key)• Old clients no longer get full MD5 after cache clear
• Prevents invalid refresh loop ✅
Code Quality
• Extracted
DEFAULT_SERVER_VERSIONconstant• Standardized comments in core files
• Removed redundant auto-discovery mechanism
Verification
• ✅ Requirement 1: Multi-field in single version (5 fields in 2.0.0)
• ✅ Requirement 2: Cross-version comparison (tested 1.5→2.2)
• ✅ 22 tests passing (
IncrementalContentUtilTest,FieldVersionRegistryTest, etc.)Core Files
• FieldVersionInitializer.java (NEW) - Registers field versions at startup
• FieldVersionRegistry.java (NEW) - Global version registry
• IncrementalContentUtil.java - Version-aware content filtering
• CacheItem.java (FIXED) - Cache refresh logic
• ConfigCacheService.java - Uses incremental MD5