fix(db): resolve resource leakage in database close()

[warku123]

What does this PR do?

Fix resource leakage in CheckPointV2Store.close() and TronDatabase.close() by ensuring dbSource.closeDB() is always executed, even when writeOptions.close() throws an exception.

Changes:

• TronDatabase.close(): Split the single try-catch block into two independent try-catch blocks for writeOptions.close() and dbSource.closeDB(), so that a failure in one does not prevent the other from executing.
• CheckPointV2Store.close(): Close the subclass-specific writeOptions first, then delegate to super.close() for parent resource cleanup, removing duplicated close logic and logging.
• CheckPointV2StoreTest: Add two test cases:
  • testCloseReleasesAllResources — verifies that dbSource.closeDB() is called during normal close.
  • testCloseDbSourceWhenWriteOptionsThrows — mocks both child and parent writeOptions.close() to throw exceptions, then verifies dbSource.closeDB() is still called.

Why are these changes required?

Previously, writeOptions.close() and dbSource.closeDB() were in the same try block in both TronDatabase.close() and CheckPointV2Store.close(). If writeOptions.close() threw an exception, dbSource.closeDB() would be skipped, causing the underlying database (LevelDB/RocksDB) to remain open and leak native resources. This is particularly problematic in environments where multiple database instances are created and destroyed.

This PR has been tested by:

• Unit Tests (CheckPointV2StoreTest — both happy path and exception scenario)
• Manual Testing

Follow up

N/A

Extra details

This is a revised version of #6621, addressing all review feedback:

• Fixed the root cause in TronDatabase.close() (parent class), not just the subclass
• Tests now cover the actual bug scenario (writeOptions throwing exceptions)
• Tests verify dbSource.closeDB() is called, which is the core guarantee of this fix
• Removed vacuous assertions, duplicate close calls in finally blocks, and redundant Javadoc

[alan-eth]

The fix for splitting the try-catch blocks is clean and directly addresses the root cause — really nice work isolating each resource cleanup independently!

One small thing: the "End to close" log moved from a finally block to a bare statement after both try-catch blocks. In the (admittedly rare) event that an unchecked Error (e.g. OutOfMemoryError) escapes from dbSource.closeDB(), this line won't execute — whereas the original finally guaranteed it would. Would it be worth wrapping both try-catch blocks in an outer try-finally?

try {
  try { writeOptions.close(); } catch (Exception e) { ... }
  try { dbSource.closeDB(); } catch (Exception e) { ... }
} finally {
  logger.info("******** End to close {}. ********", getName());
}

[warku123]

Thanks for the suggestion! Good catch on the Error case. I've moved the log into a finally on the second try-catch block instead of adding an outer try-finally — same guarantee, slightly less nesting. Updated in bcb7c0b.

[alan-eth]

Nice, putting the log in the second finally is a clean alternative — less nesting with the same guarantee. Looks good!

[halibobo1205]

[[SHOULD]]CheckPointV2Store.close() previously logged at debug on purpose — SnapshotManager.createCheckpoint() opens/closes one on every checkpoint flush. Delegating to super.close() promotes those lines to info and will spam logs.

Suggest a protected doClose() hook in the parent so the subclass can keep its debug level without duplicating logs:

// TronDatabase
@Override
public void close() {
  logger.info("******** Begin to close {}. ********", getName());
  doClose();
  logger.info("******** End to close {}. ********", getName());
}

protected void doClose() {
  try { writeOptions.close(); }
 catch (Exception e) { logger.warn("Failed to close writeOptions in {}.", getName(), e); }
  try { dbSource.closeDB(); }
  catch (Exception e) { logger.warn("Failed to close dbSource in {}.", getName(), e); }
}

// CheckPointV2Store
@Override
public void close() {
  logger.debug("******** Begin to close {}. ********", getName());
  try { writeOptions.close(); }
  catch (Exception e) { logger.warn("Failed to close writeOptions in {}.", getName(), e); }
  doClose();
  logger.debug("******** End to close {}. ********", getName());
}

[warku123]

Good catch! Implemented the doClose() hook in 39cddb5 — CheckPointV2Store.close() now logs at debug level and calls doClose() directly, so high-frequency checkpoint flushes won't spam the info log.

[warku123]

Defensive reset unrelated to this PR's resource-leakage fix, but needed to stabilize the JaCoCo overall-delta gate.

Root cause: FilterQueryTest (in org.tron.common) sets EventPluginLoader.filterQuery = {fromBlock=100, toBlock=190} at the end of testMatchFilter() with no cleanup. With forkEvery=100, this PR's new test methods shifted the JVM batch boundary, causing FilterQueryTest and BlockEventGetTest to land in the same JVM. Since start(config) does not reset filterQuery, the stale range filter caused matchFilter() to return false for block 1, skipping processTrigger entirely — 0/293 instructions covered in the PR run vs 277/293 on base.

Evidence:

• ❌ Before fix — Coverage Gate failed: https://github.com/tronprotocol/java-tron/actions/runs/24652783259/job/72081002383
• ✅ After fix — Coverage Gate passed: https://github.com/tronprotocol/java-tron/actions/runs/24767648239/job/72467952762

Fix: FilterQueryTest now resets filterQuery to null in @After, eliminating the pollution at its source. The @Before reset here is an additional guard against any other test leaving dirty singleton state.

Note: This singleton pollution pattern may exist elsewhere in the codebase — any test that writes to a static singleton (e.g. Args, EventPluginLoader, ConfigLoader) without resetting it in @After is a potential source of similar unexpected JaCoCo coverage drops when batch boundaries shift.

[halibobo1205]

approved