imbajin commented on code in PR #2871:
URL: https://github.com/apache/hugegraph/pull/2871#discussion_r4101300391
##########
hugegraph-store/hg-store-core/src/main/java/org/apache/hugegraph/store/PartitionEngine.java:
##########
@@ -577,6 +579,9 @@ public void shutdown() {
* Restart raft engine
*/
public void restartRaftNode() {
+ if (this.stateMachineError) {
+ return;
+ }
Review Comment:
Fixed in c24e5a329. Restart requests are serialized on a dedicated lock, and
the terminal flag is checked again after shutdown has joined the old FSM,
before reopening its logs. Error notification deliberately does not take that
lock, so it can complete while shutdown waits. A latch-controlled test
reproduces the old re-init during drain and now passes; a separate
queued-activity test waits until the real asynchronous check returns through
the restart gate before asserting no shutdown/init.
##########
hugegraph-store/hg-store-core/src/main/java/org/apache/hugegraph/store/raft/PartitionStateMachine.java:
##########
@@ -87,7 +88,7 @@ public void onApply(Iterator iter) {
// Leader branch, call locally
RaftOperation operation = done.getOperation();
if (handler.invoke(groupId, operation.getOp(),
operation.getReq(),
- done.getClosure())) {
+ done)) {
Review Comment:
Confirmed: my previous adapter change broke the concrete response contract.
Fixed in c24e5a329 at the common GrpcClosure.setResult boundary: unwrap
completion decorators, then write into the original typed closure while
retaining guarded callback delivery. The new tests execute real
HgStoreNodeService and HgStoreSessionImpl for BATCH/TABLE/GRAPH DELETE/CLEAN
(with storage mocked), checking results and callbacks in both success and
throwing-callback cases. The tests reproduce the previous ClassCastException
and pass after the fix.
##########
hugegraph-pd/hg-pd-core/src/main/java/org/apache/hugegraph/pd/raft/RaftStateMachine.java:
##########
@@ -94,6 +94,7 @@ public void onApply(Iterator iter) {
if (done != null) {
done.run(new Status(RaftError.EINTERNAL, t.getMessage()));
}
+ iter.setErrorAndRollback(1, new
Status(RaftError.ESTATEMACHINE, t.getMessage()));
Review Comment:
Keeping the literal 1 here: jRaft counts the current failed entry in the
rollback tail, so this means failing exactly the current entry, not a tunable
retry policy. The regression tests explicitly verify that the applied index
remains at the preceding entry. No additional constant or configuration is
needed for this fixed API argument.
--
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]
