[I] Lifecycle statistics may return stale sharding assignments from CuratorCache [shardingsphere-elasticjob]

["sandynz (via GitHub)" <gi...@apache.org>]

sandynz opened a new issue, #2531:
URL: https://github.com/apache/shardingsphere-elasticjob/issues/2531

   ## Bug Report
   
   ### Expected behavior
   
   Lifecycle statistics should use the sharding assignment currently stored in the registry center.
   
   ### Actual behavior
   
   When a running job has registered a `CuratorCache`, lifecycle statistics can return a previous
   `/<jobName>/sharding/<item>/instance` value after ZooKeeper already contains the new assignment.
   
   This can cause:
   
   - `JobStatisticsAPI.getJobBriefInfo()` to report `SHARDING_FLAG` for a valid assignment;
   - `ShardingStatisticsAPI.getShardingInfo()` to return the previous instance ID and server IP.
   
   ### Reproduction
   
   A deterministic harness captures a real cached assignment, freezes only that path through a test adapter,
   updates the same ZooKeeper path, and then invokes the real lifecycle implementations.
   
   Observed on `0694c8f6b376b166324992be5431f6d4be131c66`:
   
   ```text
   JOB_STATISTICS_STALE_ASSIGNMENT cached=10.0.0.1@-@old direct=10.0.0.2@-@new lifecycleStatus=SHARDING_FLAG
   SHARDING_STATISTICS_STALE_ASSIGNMENT cached=10.0.0.1@-@old direct=10.0.0.2@-@new instanceId=10.0.0.1@-@old serverIp=10.0.0.1
   RESULT jobStatisticsStaleAssignment=true shardingStatisticsStaleAssignment=true
   ```
   
   The underlying real Curator cache propagation window was independently reproduced in #2526. The frozen
   adapter makes the lifecycle consumer test deterministic; it does not estimate the natural window frequency.
   
   ### Environment
   
   - ElasticJob: `3.0.6-SNAPSHOT`
   - Commit: `0694c8f6b376b166324992be5431f6d4be131c66`
   - Curator: `5.9.0`
   - ZooKeeper client: `3.9.5`
   - ZooKeeper server: `3.9.3`
   - JDK: `21.0.10`
   
   ### Root cause
   
   Both of the following methods read assignment values with cached `CoordinatorRegistryCenter.get()`:
   
   - `JobStatisticsAPIImpl.isHasShardingFlag()`;
   - `ShardingStatisticsAPIImpl.getShardingInfo()`.
   
   ZooKeeper updates and Curator cache propagation are asynchronous, so these management queries can expose a
   previous assignment.
   
   ### Proposed change
   
   Use `CoordinatorRegistryCenter.getDirectly()` for sharding assignment values in the two lifecycle statistics
   paths above. Keep `ZookeeperRegistryCenter.get()`, per-job caches, provider SPI signatures, and kernel cached
   reads unchanged.
   
   Add focused tests that preserve a stale assignment snapshot while asserting that lifecycle results follow the
   authoritative assignment.
   
   ### Scope boundary
   
   This issue only removes the local-cache stale source for assignment values. It does not promise an atomic
   snapshot across assignment, instance metadata, or sharding status marker nodes. Instance deletion races should
   be handled separately.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Lifecycle statistics may return stale sharding assignments from CuratorCache [shardingsphere-elasticjob]

["sandynz (via GitHub)" <gi...@apache.org>]

sandynz closed issue #2531: Lifecycle statistics may return stale sharding assignments from CuratorCache
URL: https://github.com/apache/shardingsphere-elasticjob/issues/2531


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org