imbajin commented on code in PR #3418:
URL: https://github.com/apache/hugegraph/pull/3418#discussion_r4393474806
##########
hugegraph-pd/hg-pd-core/src/main/java/org/apache/hugegraph/pd/StoreNodeService.java:
##########
@@ -497,7 +518,7 @@ public synchronized List<Metapb.Shard>
allocShards(Metapb.Graph graph, int partI
*/
public synchronized List<Metapb.Shard> reallocShards(Metapb.ShardGroup
shardGroup) throws
PDException {
- List<Metapb.Store> stores = storeInfoMeta.getActiveStores();
+ List<Metapb.Store> stores = getPlacementStores();
Review Comment:
**[P2] Allow a blocked drain to resume after eligible capacity is restored**
Excluding the draining Store here exposes a failed-transition path that
cannot be resumed by repeating the management request:
1. Start with three live `Up` Stores, `minStoreCount=3`, and a three-member
shard group.
2. Request `Exiting` for one Store through `POST /store/{storeId}`.
[`updateStore()`](https://github.com/apache/hugegraph/blob/b84bf81b8962507027d811206d8fa8a590e8b9d0/hugegraph-pd/hg-pd-core/src/main/java/org/apache/hugegraph/pd/StoreNodeService.java#L295-L317)
persists `Exiting` before calling `storeTurnoff()`. This new eligibility
filter leaves only two destinations, so reallocation throws
`LESS_ACTIVE_STORE`; the original group remains unchanged.
3. Add a fourth live `Up` Store, then repeat the same `Exiting` request. The
state-equality guard skips `storeTurnoff()`, so the request returns without
resuming the drain.
The background paths do not recover this case: [partition
patrol](https://github.com/apache/hugegraph/blob/b84bf81b8962507027d811206d8fa8a590e8b9d0/hugegraph-pd/hg-pd-core/src/main/java/org/apache/hugegraph/pd/TaskScheduleService.java#L257-L276)
sees the expected shard count and only separately processes `Tombstone`
Stores;
[balancing](https://github.com/apache/hugegraph/blob/b84bf81b8962507027d811206d8fa8a590e8b9d0/hugegraph-pd/hg-pd-core/src/main/java/org/apache/hugegraph/pd/TaskScheduleService.java#L301-L339)
now excludes `Exiting` Stores from the source map too. Heartbeats and
re-registration preserve the blocked intent.
Please make repeated/pending `Exiting` intent retry the unfinished drain
after capacity returns, or safely roll back a failed transition. A regression
should exercise the management path: insufficient eligible capacity → failed
transition → add capacity → repeat the same request → migration is scheduled,
without lowering the minimum or toggling through `Up`.
Validation: independently cross-checked source paths at
`b84bf81b8962507027d811206d8fa8a590e8b9d0`; not reproduced in a live cluster.
This is a drain-recovery availability issue, not a data-loss claim.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
