Fix for listCapacity with fetchlatest parameter causing RuntimeException

[abh1sar]

Description

This PR fixes #12397

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

Tested listCapacity api with fetchlatest parameter. No exceptions were observed.
Tested with the Fetch Latest button on the capacity dashboard. Capacities were lister correctly.

How did you try to break this feature and the system with this change?

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 17.76%. Comparing base (56a39e6) to head (da4377e).
⚠️ Report is 20 commits behind head on 4.20.

Files with missing lines	Patch %	Lines
...rc/main/java/com/cloud/alert/AlertManagerImpl.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               4.20   #12421      +/-   ##
============================================
+ Coverage     16.23%   17.76%   +1.52%     
- Complexity    13378    15863    +2485     
============================================
  Files          5657     5923     +266     
  Lines        498866   530603   +31737     
  Branches      60545    64835    +4290     
============================================
+ Hits          81011    94273   +13262     
- Misses       408821   425783   +16962     
- Partials       9034    10547    +1513     

Flag	Coverage Δ
uitests	3.59% <ø> (-0.41%)	⬇️
unittests	18.85% <0.00%> (+1.75%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[abh1sar]

@blueorangutan package

[blueorangutan]

@abh1sar a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[vishesh92]

clgtm

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16357

[Copilot]

Pull request overview

This PR fixes a RuntimeException that occurs when using the listCapacity API with the fetchlatest parameter. The issue is caused by nested transaction handling when updateCapacityForHost (which has the @DB annotation and manages its own transactions) is wrapped in an additional Transaction.execute block within a multi-threaded executor context.

Changes:

• Removed redundant Transaction.execute wrapper around updateCapacityForHost call in recalculateHostCapacities()
• Simplified the code by calling updateCapacityForHost directly, relying on its @DB annotation for transaction management

---

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

[Copilot]

The change correctly removes the redundant Transaction.execute wrapper. However, there's an inconsistency with recalculateStorageCapacities() (lines 313-347) which still uses Transaction.execute wrapper. For consistency and to prevent similar nested transaction issues, consider applying the same pattern if the methods called within have their own transaction management (e.g., if they use @db annotation or Transaction.execute internally).