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: 
[email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to