fix(net): exit solidity node block sync on shutdown

[317787106]

What does this PR do?

1. TronNetDelegate — wrap LockSupport.park() in a while (!hitDown && !Thread.currentThread().isInterrupted()) loop so that spurious unparks (e.g. from Thread.interrupt() in close()) cannot trigger the System.exit(0) path prematurely, and so the hit-thread exits cleanly when the Spring context is destroyed.

2. SolidityNode — fix a shutdown race in getBlockByNum(): when a gRPC exception is thrown while the node is shutting down (!flag || isHitDown()), break out immediately instead of sleeping exceptionSleepTime (1 s) and retrying.

3. ShieldedReceiveTest.pushSameSkAndScanAndSpend — fix a test isolation bug and a performance regression:

   • The test relied on the genesis bypass in validBlock() (latestBlockHeaderNumber == 0 → return true) to skip DPoS schedule validation. When prior tests cause the consensus background task to produce blocks, this bypass no longer applies and the block push fails with ValidateScheduleException.
   • Replace hardcoded System.currentTimeMillis() timestamps with nextScheduledTime(), which looks up the nearest slot where the witness is actually scheduled according to DposSlot.
   • Stop ConsensusService before manual block pushes: DposTask shares the same localwitness key and would race to produce blocks at the same slot, triggering switchFork and making the test slow.

4. reference.conf — remove the stale "Keys that cannot auto-bind" comment block; those implementation details belong in the source classes, not in the config template.

5. README.md — surface reference.conf alongside config.conf in the configuration-file list so users know a built-in defaults template exists (added in v4.8.2).

Why are these changes required?

• The single LockSupport.park() call could be woken by Thread.interrupt() from close(), causing the process to reach System.exit(0) before hitDown was ever set. With the while-loop fix, close() calling interrupt() caused a busy-spin because park() returns immediately when interrupted but the loop never exited — adding the isInterrupted() guard lets the thread exit cleanly.
• During shutdown, a transient gRPC exception in getBlockByNum() triggered a 1-second sleep and an unnecessary retry loop, delaying clean exit and producing noisy error logs.
• pushSameSkAndScanAndSpend passed in isolation because the chain started at genesis (block 0), bypassing DPoS validation. In a full test run, the consensus background task produces blocks before this test runs, advancing the head past 0 and exposing the missing schedule-aware timestamp logic.
• The reference.conf comment described internal normalisation details that have since been refactored into the Java classes.
• reference.conf was introduced in v4.8.2 but not mentioned in the README.

This PR has been tested by:

• Unit Tests
  • testGetBlockByNumNoErrorOnExceptionDuringShutdown: verifies the shutdown race fix — method breaks in < 500 ms; without the fix a 1-second sleep fires first.
  • pushSameSkAndScanAndSpend: now stable in both single-test and full-suite runs.
• Manual Testing

Follow up

Extra details

[3for]

[SHOULD] pushSameSkAndScanAndSpend still appears to leak state into subsequent tests through the consensus background task.

ShieldedReceiveTest.java (line 2409) calls consensusService.stop(), and ShieldedReceiveTest.java (line 2537) attempts to restore it with consensusService.start() in the finally block.

However, DposTask.stop() sets isRunning = false (DposTask.java:82), while DposTask.init() does not reset it back to true (DposTask.java:46). As a result, after start() creates a new executor, the newly submitted runnable immediately exits because isRunning is still false, so block production is not actually resumed.

This means the test can still affect subsequent tests running in the same Spring context.

Consider either:

• resetting isRunning = true in DposTask.init() before creating the executor, or
• isolating this test in a dedicated context/fixture instead of stopping and restarting a shared singleton service.

[317787106]

Actually, other testcases don't use consensusService. But reset DposTask's isRunning by reflection in finally block is still ok.

[3for]

[SHOULD] The test appears to work around a real production issue via reflection rather than fixing the root cause.

DposTask.stop() sets isRunning = false, but DposTask.init() never resets it (DposTask.java:43,84). As a result, any ConsensusService.stop() → start() cycle leaves block production permanently disabled—not just in tests, but in production as well.

The actual fix seems to be a single line:

isRunning = true;

at the beginning of DposTask.init() (or start()).

That would also allow the test to simply call stop()/start() without resorting to reflection.

As written, the underlying defect remains, and the test reaches into a private volatile field via reflection. This is fairly brittle—a field rename could silently break the test at runtime.

Recommend fixing DposTask itself and removing the reflection from the test.

[317787106]

The main code should not be modified solely to make the test cases pass.

[3for]

The concern is not about modifying production code for the sake of a test. The test exposed a potential production issue: any ConsensusService.stop() → start() cycle leaves block production permanently disabled.

If such a lifecycle transition cannot occur in production, then this can be considered a test-only concern and safely ignored. Otherwise, it may indicate a real bug in the service lifecycle handling.

[317787106]

This lifecycle transition ConsensusService.stop() → start() cannot occur in production. So there is no need to change it.