Skip to content

Conversation

@mingri31164
Copy link
Contributor

@mingri31164 mingri31164 commented Nov 4, 2025

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)

  • Pre-registers extension fields with their introduction versions
    executeTimeOut, isAlarm, capacityAlarm"2.0.0"
  • Centralized version management for all fields
  • Eliminates hardcoded version checks

2. FieldVersionRegistry (NEW)

  • Global static registry: fieldName → introducedVersion
  • Thread-safe ConcurrentHashMap implementation
  • putIfAbsent ensures earliest version wins
  • Persistent across requests

3. IncrementalContentUtil (Enhanced)

  • Version-aware filtering based on registry
  • Core parameters: always visible (bypass version check)
  • Extension fields: filtered by clientVersion >= fieldVersion
  • Dynamic field discovery with fallback to current server version

How It Works

  1. Server Startup:
    FieldVersionInitializer registers known fields to FieldVersionRegistry
    Example: registerField("executeTimeOut", "2.0.0")

  2. Client Request (e.g., Client 1.5.0):
    IncrementalContentUtil.getVersionedContent(param, "1.5.0")
    resolveFieldRules() queries FieldVersionRegistry
    executeTimeOut requires "2.0.0" but client is "1.5.0"
    Field filtered out → No invalid refresh ✅

  3. Config Update:
    CacheItem.clearVersionMd5() clears cache
    getMd5() returns null (FIXED: was returning full MD5)
    → Triggers recalculation with correct version filtering


Critical Fixes

  1. 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

  2. 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 ✅

  3. Code Quality
    • Extracted DEFAULT_SERVER_VERSION constant
    • 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

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.

1 participant