Path workers, allow node operators to configure threads used

[shortthefomo]

High Level Overview of Change

Introduce a new configurable limit for pathfinding workers ([path_workers]), replacing the previous jt_update_pf_limit. This allows administrators to control the maximum number of concurrently running jtUPDATE_PF jobs in the JobQueue, which impacts path update and full order book update throughput. The limit is now capped at 3/4 of the configured [workers] (rounded down), with a minimum cap of 2, to prevent system overload while allowing better utilization of available threads.

Additionally, tie the number of pathfinding threads (mPathFindThread) dynamically to the configured workers, ensuring scalability.

This change does heavily impact a node CPU use when configured away from the default.

This PR was also opened against xrpld XRPLF/rippled#6604

Context of Change

The pathfinding thread count is now tied to workers to avoid fixed low limits that don't scale. This improves performance on larger deployments while preventing resource exhaustion.

The core finding is that because pathfinding and order books updates are blocked behind a single thread, all other requests on todo that get stuck behind the slowest request. As xrpld stands today.

It is recommended that pathfinding nodes do run in memory mode along with this patch.

Every effort has been made to make sure the node is not starved when servicing large number of requests. Even so a validator should not be configuring their node to discover paths. This config is meant only for node setup to discover paths.

API Impact

• Public API: New feature (new methods and/or new fields)
• Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• Peer protocol change (must be backward compatible or bump the peer protocol version)

No API impact - this is purely a configuration change.

Before / After

Before:

• jt_update_pf_limit was limited to 1
• Pathfinding threads: Fixed at 1 and Job Queue of Fixed minimum of 2, not tied to workers
• Limiting the pathfinding operation effetely to 1 thread where all requests stack up if a longer pathfinder operation is added to the node effectively everyone using the node has to wait for it.

After:

• Config option: [path_workers] (default 2, max 3/4 of workers rounded down, min cap 2)
• Limit cap: 3/4 of workers (min 2), enforced at runtime
• Allows multiple threads to service the requests, where by if a longer running path find operation on the node is requested not everyone is stuck waiting for that to complete.

Example: With [workers] = 14, max [path_workers] is now 10 (vs. previous 1).

Test Plan

• Build verification: Code compiles successfully with CMake.
• Config validation: Invalid values (e.g., > 3/4 workers) are rejected with clear error messages.
• Runtime behavior: Server starts with valid configs and enforces limits dynamically.

To test: Set [path_workers] to a value > 3/4 of [workers] and verify startup failure with appropriate error.

Future Tasks

None - this completes the pathfinding worker configurability improvements.

[sentinel-ai-reviewer]

Sentinel Security Review

Priority	File	Issue	Category
🟡 MEDIUM	src/xrpld/app/main/Application.cpp:272	The order of checks in jobQueueThreads() (standalone first at line 272, then WOR...	edge_case
🟡 MEDIUM	src/xrpld/core/detail/Config.cpp:718	The effectiveWorkers lambda (line 717-734) checks if (WORKERS) BEFORE `if (sta...	state_machine

Stats: 2 issues · 2 medium · reviewed 0 files

Available Commands

PR-Level (top-level PR comment)

Command	Description
/audit	Re-trigger a security audit
/config	Show effective Sentinel configuration
/help	Show available commands

Finding-Level (reply to a Sentinel inline comment)

Command	Description
/fp	Mark finding as false positive
/fix	Generate a fix for this issue
/explain	Explain the finding in detail
/validate	Re-validate with additional context
/dismiss	Dismiss this finding

---

Sentinel AI

[codecov]

Codecov Report

❌ Patch coverage is 71.71053% with 43 lines in your changes missing coverage. Please review.
✅ Project coverage is 66.50%. Comparing base (dd9e605) to head (121ad0a).

Files with missing lines	Patch %	Lines
src/xrpld/app/paths/PathRequests.cpp	70.00%	10 Missing and 11 partials ⚠️
src/xrpld/core/detail/Config.cpp	35.00%	7 Missing and 6 partials ⚠️
src/xrpld/app/main/Application.cpp	84.61%	4 Missing and 4 partials ⚠️
src/xrpld/app/ledger/detail/LedgerMaster.cpp	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #724      +/-   ##
==========================================
- Coverage   66.52%   66.50%   -0.03%     
==========================================
  Files         831      831              
  Lines       78008    78069      +61     
  Branches    44269    44299      +30     
==========================================
+ Hits        51893    51917      +24     
- Misses      17785    17809      +24     
- Partials     8330     8343      +13     

☔ 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.

[RichardAH]

@shortthefomo needs clang-format please