Fix folderManager NPE issue in WALNode when starting iotdb in a disk-full state

[OneSizeFitsQuorum]

This PR addresses an NPE issue in WALNode creation that occurs when IoTDB starts with a full disk. When the disk is full at startup, the FolderManager initialization in the constructor fails, leaving it null. If disk space is later freed, subsequent WAL node creation attempts fail with NPE because the folderManager is still null.

[Copilot]

Pull request overview

This PR addresses an NPE issue in WALNode creation that occurs when IoTDB starts with a full disk. When the disk is full at startup, the FolderManager initialization in the constructor fails, leaving it null. If disk space is later freed, subsequent WAL node creation attempts fail with NPE because the folderManager is still null.

Key Changes:

• Adds lazy initialization of FolderManager in the createWALNode method to handle recovery after disk space becomes available

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 38.87%. Comparing base (f4d628a) to head (cd69d06).

Files with missing lines	Patch %	Lines
...wal/allocation/AbstractNodeAllocationStrategy.java	80.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #16869      +/-   ##
============================================
- Coverage     38.87%   38.87%   -0.01%     
  Complexity      207      207              
============================================
  Files          5021     5021              
  Lines        333052   333058       +6     
  Branches      42389    42389              
============================================
- Hits         129487   129484       -3     
- Misses       203565   203574       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Race condition: Multiple threads can simultaneously check folderManager.get() == null and proceed to create multiple FolderManager instances. The comment on line 61 states "already in lock, so no need to synchronized", but AtomicReference alone doesn't prevent this race condition. The check-then-set pattern is not atomic. Consider using synchronized double-checked locking:

if (folderManager.get() == null) {
  synchronized (folderManager) {
    if (folderManager.get() == null) {
      folderManager.set(new FolderManager(...));
    }
  }
}

Alternatively, use compareAndSet() for atomic updates.

Suggested change

	// already in lock, so no need to synchronized
	if (folderManager.get() == null) {
	folderManager.set(
	new FolderManager(
	Arrays.asList(commonConfig.getWalDirs()), DirectoryStrategyType.SEQUENCE_STRATEGY));
	// Atomically initialize folderManager if null
	while (folderManager.get() == null) {
	FolderManager newManager = new FolderManager(
	Arrays.asList(commonConfig.getWalDirs()), DirectoryStrategyType.SEQUENCE_STRATEGY);
	if (folderManager.compareAndSet(null, newManager)) {
	break;
	}
	// else, another thread set it, retry check

[Copilot]

Potential NPE: Even after the null check and re-initialization attempt (lines 62-66), folderManager.get() could still be null if the FolderManager constructor throws DiskSpaceInsufficientException again. In this case, line 67 will throw NPE when calling .get().getNextWithRetry(). The exception from line 63-65 is not caught here, so it would propagate up, but if it were caught elsewhere, this would be an NPE risk. Consider adding a null check after the initialization attempt or handling the case where re-initialization fails.

[Copilot]

Missing test coverage for the disk recovery scenario: The new lazy initialization logic (lines 62-66) that handles disk space recovery is not covered by tests. The existing tests in FirstCreateStrategyTest don't simulate a disk-full-at-startup followed by disk-space-recovery scenario. Consider adding a test that:

1. Simulates disk full at construction time (folderManager becomes null)
2. Verifies WALFakeNode is returned initially
3. Frees disk space
4. Verifies successful WAL node creation on retry (folderManager is recreated)