8000 test: enable unit tests to work with variable reference fee by vvysokikh1 · Pull Request #5145 · XRPLF/rippled · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

test: enable unit tests to work with variable reference fee #5145

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 34 commits into from
Mar 25, 2025

Conversation

vvysokikh1
Copy link
Collaborator
@vvysokikh1 vvysokikh1 commented Sep 20, 2024

High Level Overview of Change
This PR is a continuation of work done in: #5118
Fix remaining unit tests to be able to process reference fee value other than 10.

Context of Change
In preparation for potential reference fee change we would like to verify that fee change works as expected. The first step is to fix all unit tests to be able to work with different reference fee values.

Type of Change
[x ] Tests (you added tests for code that already exists, or your new feature included in this PR)
API Impact
None

Test Plan
Tested following reference fee values: 10, 20, 50, 100, 200, 500, 1000 by changing https://github.com/vvysokikh1/rippled/blob/2f432e812cb773048530ebfaf2e0e6def51e3cc2/src/test/jtx/impl/envconfig.cpp#L47

@vvysokikh1 vvysokikh1 changed the title [WIP] test: enable unit tests to work with variable reference fee test: enable unit tests to work with variable reference fee Sep 25, 2024
@vvysokikh1 vvysokikh1 marked this pull request as ready for review September 25, 2024 13:17
Copy link
codecov bot commented Sep 25, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.1%. Comparing base (67028d6) to head (b9a5163).
Report is 1 commits behind head on develop.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff            @@
##           develop   #5145     +/-   ##
=========================================
- Coverage     78.1%   78.1%   -0.0%     
=========================================
  Files          790     790             
  Lines        67990   67989      -1     
  Branches      8253    8254      +1     
=========================================
- Hits         53092   53088      -4     
- Misses       14898   14901      +3     

see 4 files with indirect coverage changes

Impacted file tree graph

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

@Bronek
Copy link
Collaborator
Bronek commented Oct 14, 2024

Test Plan Tested following reference fee values: 10, 20, 50, 100, 200, 500, 1000 by changing https://github.com/vvysokikh1/rippled/blob/2f432e812cb773048530ebfaf2e0e6def51e3cc2/src/test/jtx/impl/envconfig.cpp#L47

Can you pls add a command line option to set this value ? It will probably go somewhere in app/main/Main.cpp (look for sections guarded by #ifdef ENABLE_TESTS )

@vvysokikh1
8000
Copy link
Collaborator Author
vvysokikh1 commented Oct 15, 2024

Test Plan Tested following reference fee values: 10, 20, 50, 100, 200, 500, 1000 by changing https://github.com/vvysokikh1/rippled/blob/2f432e812cb773048530ebfaf2e0e6def51e3cc2/src/test/jtx/impl/envconfig.cpp#L47

Can you pls add a command line option to set this value ? It will probably go somewhere in app/main/Main.cpp (look for sections guarded by #ifdef ENABLE_TESTS )

This is actually quite tricky to do in runtime. Almost all tests allocate the Env and Config independently and it would require significant effort to propagate the fee value from startup params.

Feasible option is to make it compile time setting in CMake

@Bronek
Copy link
Collaborator
Bronek commented Oct 15, 2024

Test Plan Tested following reference fee values: 10, 20, 50, 100, 200, 500, 1000 by changing https://github.com/vvysokikh1/rippled/blob/2f432e812cb773048530ebfaf2e0e6def51e3cc2/src/test/jtx/impl/envconfig.cpp#L47

Can you pls add a command line option to set this value ? It will probably go somewhere in app/main/Main.cpp (look for sections guarded by #ifdef ENABLE_TESTS )

This is actually quite tricky to do in runtime. Almost all tests allocate the Env and Config independently and it would require significant effort to propagate the fee value from startup params.

Feasible option is to make it compile time setting in CMake

Yeah in that case just pls add an option to CMake (files RippledSettings.cmake and RippledCore.cmake); it is important that we can run unit tests with an arbitrary fee, so the new features do not revert to the hardcoded default 10.

@vvysokikh1
Copy link
Collaborator Author

Test Plan Tested following reference fee values: 10, 20, 50, 100, 200, 500, 1000 by changing https://github.com/vvysokikh1/rippled/blob/2f432e812cb773048530ebfaf2e0e6def51e3cc2/src/test/jtx/impl/envconfig.cpp#L47

Can you pls add a command line option to set this value ? It will probably go somewhere in app/main/Main.cpp (look for sections guarded by #ifdef ENABLE_TESTS )

This is actually quite tricky to do in runtime. Almost all tests allocate the Env and Config independently and it would require significant effort to propagate the fee value from startup params.
Feasible option is to make it compile time setting in CMake

Yeah in that case just pls add an option to CMake (files RippledSettings.cmake and RippledCore.cmake); it is important that we can run unit tests with an arbitrary fee, so the new features do not revert to the hardcoded default 10.

I've added a draft PR with this workflow added: #5159

@vvysokikh1 vvysokikh1 requested review from Bronek and ximinez February 28, 2025 13:49
@vvysokikh1 vvysokikh1 force-pushed the other_tests_variable_reference_fee branch from f1ba775 to 167eed3 Compare March 3, 2025 14:38
env,
{.owner = bad,
.seq = seq(1),
.fee = static_cast<int>(env.current()->fees().base.drops()),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and below, can you use safe_cast or unsafe_cast instead, if possible?

Make sure to include the <xrpl/basics/safe_cast.h> header. It may compile without it, but wouldn't follow the "Include-What-You-Use" spirit; we haven't yet enabled clang-tidy that would check/do this for you, so for now we have to be vigilant ourselves.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the motivation? I've seen you doing that in other PR, but I struggle to understand what is the purpose of this.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per @ximinez on a different PR:

we have two sets of overrides: safe_cast and unsafe_cast that specify at compile time whether or not all the values of the source type can fit into the destination type.

Now, if there's little value gained, I'd rather see us rip it out completely everywhere, rather than having it only partially being used. I personally find them not very useful, especially because data types have different sizes on different platforms, so in the end what is a safe_cast on one platform ends up being an unsafe_cast on another, which then doesn't compile on one of them, and the end result is just using static_cast instead. It took me tons of whack-a-mole commits to figure out which of these functions worked on all three platforms.

@ximinez: Any strong opinions on maintaining use of (un)safe cast whenever possible and preferring its use if it compiles on all platforms, or can we just get rid of it (in a separate PR) as the benefits do not outweigh the pains of getting code to compile everywhere when using them?

@@ -70,38 +80,47 @@ struct Oracle_test : public beast::unit_test::suite
{"XRP", "CAD", 740, 1},
{"XRP", "AUD", 740, 1},
},
.fee = static_cast<int>(env.current()->fees().base.drops()),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at src/test/jtx/Oracle.h and src/test/jtx/impl/Oracle.cpp, when setting Oracle args they won't be updated if they are not provided.

So, here and below, you don't need to additionally include .fee = static_cast<int>(env.current()->fees().base.drops()) in these oracle.set calls, unless the fee is different from what the oracle was initially created with.

This applies to both set using CreateArgs or UpdateArgs as input, since they end up calling the same function. It may also apply to the remove calls too, where including the same base fee as was already in use is unnecessary.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you look at CreateArgs struct, it initializes fee with 10 (hardcoded). And there's no way of initializing it in a different way as it's a part of Env.

This is the only way to construct CreateArgs (and Oracle) with correct fee.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There may be value in removing the:

void
Oracle::set(CreateArg const& arg)
{
    set(UpdateArg{...})
}

function. You can still construct a new Oracle during which a default fee is used unless overridden, but you are forced to be explicit when calling set as only the specified values are used to update the oracle.

Alternatively, in the tests below you should be able to replace set.(CreateArg by set.(UpdateArg and leave off the fee. This should work since the oracle is already created via a CreateArg that already puts the default values in place, unless overridden.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a pretty big change unfortunately and I'm not keen on doing such refactoring.

@@ -2017,6 +2016,7 @@ struct PayChan_test : public beast::unit_test::suite
rmAccount(env, bob, carol);
BEAST_EXPECT(!env.closed()->exists(keylet::account(bob.id())));

auto const feeDrops = env.current()->fees().base;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe rename this to baseFee for consistency?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is (kind of) consistent with this particular file

Copy link
Collaborator
@bthomee bthomee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost good to go. I'm wondering, in a possible follow-up PR, whether we can make it a lot harder to forget to close the test ledger by making it explicit. For instance, the various env function calls, such as fund, offer, and trust could take an extra parameter, bool close = true, which would then call env.close() unless the argument is explicitly set to false.

Comment on lines 2464 to 2474
// Optionally pre-establish a trustline between gw and acct.
if (t.preTrust == gwPreTrust)
env(trust(gw, acct["USD"](1)));
env.close();

// Optionally pre-establish a trustline between acct and gw.
// Note this is not really part of the test, so we expect there
// to be enough XRP reserve for acct to create the trust line.
if (t.preTrust == acctPreTrust)
env(trust(acct, USD(1)));

env.close();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These three env.close() calls here and above (GitHub only allowed me to select a limited number of lines), should they be inside the if statement, since there's no point in calling it if the env(trust(...)) call isn't made?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah they could be inside of the if-block, but at the same time there's no harm if empty ledger closes, so I'm not worried about this

Comment on lines +763 to +766

env(offer(bob, usdOffer2, xrpOffer2), ter(tesSUCCESS));
env.fund(r + f, alice);

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and below, shouldn't there be env.close() calls here after env.fund(..)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I now have a better context to answer.

In this whole test, there's no .close() at all. So, whichever transactions happen, they happen in the order the code is written. So basically what you see is what you get. No problems with this.

The problem would happen on the first .close(). All transactions would be reapplied, and the ordering of this reapplication would be dependent on fee and other factors.

@vvysokikh1
Copy link
Collaborator Author

Almost good to go. I'm wondering, in a possible follow-up PR, whether we can make it a lot harder to forget to close the test ledger by making it explicit. For instance, the various env function calls, such as fund, offer, and trust could take an extra parameter, bool close = true, which would then call env.close() unless the argument is explicitly set to false.

From the moment we enable different reference fee testing, it will be not easy to push the tests that break this since they would fail on CI. We could technically add some additional precautions to make ledger close after fund, but I'm not capable to answer how much efforts we would need to make it work. There's plenty of tests that don't close ledger at all so modifying all those would be grind job

@vvysokikh1 vvysokikh1 added the Ready to merge *PR author* thinks it's ready to merge. Has passed code review. Perf sign-off may still be required. label Mar 25, 2025
@bthomee bthomee merged commit 2bc5cb2 into XRPLF:develop Mar 25, 2025
22 checks passed
Tapanito pushed a commit to Tapanito/rippled that referenced this pull request Mar 27, 2025
Fix remaining unit tests to be able to process reference fee values other than 10.
bthomee added a commit that referenced this pull request May 18, 2025
* refactor: Remove unused and add missing includes (#5293)

The codebase is filled with includes that are unused, and which thus can be removed. At the same time, the files often do not include all headers that contain the definitions used in those files. This change uses clang-format and clang-tidy to clean up the includes, with minor manual intervention to ensure the code compiles on all platforms.

* refactor: Calculate numFeatures automatically (#5324)

Requiring manual updates of numFeatures is an annoying manual process that is easily forgotten, and leads to frequent merge conflicts. This change takes advantage of the `XRPL_FEATURE` and `XRPL_FIX` macros, and adds a new `XRPL_RETIRE` macro to automatically set `numFeatures`.

* refactor: Improve ordering of headers with clang-format (#5343)

Removes all manual header groupings from source and header files by leveraging clang-format options.

* Rename "deadlock" to "stall" in `LoadManager` (#5341)

What the LoadManager class does is stall detection, which is not the same as deadlock detection. In the condition of severe CPU starvation, LoadManager will currently intentionally crash rippled reporting `LogicError: Deadlock detected`. This error message is misleading as the condition being detected is not a deadlock. This change fixes and refactors the code in response.

* Adds hub.xrpl-commons.org as a new Bootstrap Cluster (#5263)

* fix: Error message for ledger_entry rpc (#5344)

Changes the error to `malformedAddress` for `permissioned_domain` in the `ledger_entry` rpc, when the account is not a string. This change makes it more clear to a user what is wrong with their request.

* fix: Handle invalid marker parameter in grpc call (#5317)

The `end_marker` is used to limit the range of ledger entries to fetch. If `end_marker` is less than `marker`, a crash can occur. This change adds an additional check.

* fix: trust line RPC no ripple flag (#5345)

The Trustline RPC `no_ripple` flag gets set depending on `lsfDefaultRipple` flag, which is not a flag of a trustline but of the account root. The `lsfDefaultRipple` flag does not provide any insight if this particular trust line has `lsfLowNoRipple` or `lsfHighNoRipple` flag set, so it should not be used here at all. This change simplifies the logic.

* refactor: Updates Conan dependencies: RocksDB (#5335)

Updates RocksDB to version 9.7.3, the latest version supported in Conan 1.x. A patch for 9.7.4 that fixes a memory leak is included.

* fix: Remove null pointer deref, just do abort (#5338)

This change removes the existing undefined behavior from `LogicError`, so we can be certain that there will be always a stacktrace.

De-referencing a null pointer is an old trick to generate `SIGSEGV`, which would typically also create a stacktrace. However it is also an undefined behaviour and compilers can do something else. A more robust way to create a stacktrace while crashing the program is to use `std::abort`, which we have also used in this location for a long time. If we combine the two, we might not get the expected behaviour - namely, the nullpointer deref followed by `std::abort`, as handled in certain compiler versions may not immediately cause a crash. We have observed stacktrace being wiped instead, and thread put in indeterminate state, then stacktrace created without any useful information.

* chore: Add PR number to payload (#5310)

This PR adds one more payload field to the libXRPL compatibility check workflow - the PR number itself.

* chore: Update link to ripple-binary-codec (#5355)

The link to ripple-binary-codec's definitions.json appears to be outdated. The updated link is also documented here: https://xrpl.org/docs/references/protocol/binary-format#definitions-file

* Prevent consensus from getting stuck in the establish phase (#5277)

- Detects if the consensus process is "stalled". If it is, then we can declare a 
  consensus and end successfully even if we do not have 80% agreement on
  our proposal.
  - "Stalled" is defined as:
    - We have a close time consensus
    - Each disputed transaction is individually stalled:
      - It has been in the final "stuck" 95% requirement for at least 2
        (avMIN_ROUNDS) "inner rounds" of phaseEstablish,
      - and either all of the other trusted proposers or this validator, if proposing,
        have had the same vote(s) for at least 4 (avSTALLED_ROUNDS) "inner
        rounds", and at least 80% of the validators (including this one, if
        appropriate) agree about the vote (whether yes or no).
- If we have been in the establish phase for more than 10x the previous
  consensus establish phase's time, then consensus is considered "expired",
  and we will leave the round, which sends a partial validation (indicating
  that the node is moving on without validating). Two restrictions avoid
  prematurely exiting, or having an extended exit in extreme situations.
  - The 10x time is clamped to be within a range of 15s
    (ledgerMAX_CONSENSUS) to 120s (ledgerABANDON_CONSENSUS).
  - If consensus has not had an opportunity t
7438
o walk through all avalanche
    states (defined as not going through 8 "inner rounds" of phaseEstablish),
    then ConsensusState::Expired is treated as ConsensusState::No.
- When enough nodes leave the round, any remaining nodes will see they've
  fallen behind, and move on, too, generally before hitting the timeout. Any
  validations or partial validations sent during this time will help the
  consensus process bring the nodes back together.

* test: enable TxQ unit tests work with variable reference fee (#5118)

In preparation for a potential reference fee change we would like to verify that fee change works as expected. The first step is to fix all unit tests to be able to work with different reference fee values.

* test: enable unit tests to work with variable reference fee (#5145)

Fix remaining unit tests to be able to process reference fee values other than 10.

* Intrusive SHAMap smart pointers for efficient memory use and lock-free synchronization (#5152)

The main goal of this optimisation is memory reduction in SHAMapTreeNodes by introducing intrusive pointers instead of standard std::shared_ptr and std::weak_ptr.

* refactor: Move integration tests from 'examples/' into 'tests/' (#5367)

This change moves `examples/example` into `tests/conan` to make it clear it is an integration test, and adjusts the `conan` CI job accordingly

* test: enable compile time param to change reference fee value (#5159)

Adds an extra CI pipeline to perform unit tests using different values for fees.

* Fix undefined uint128_t type on Windows non-unity builds (#5377)

As part of import optimization, a transitive include had been removed that defined `BOOST_COMP_MSVC` on Windows. In unity builds, this definition was pulled in, but in non-unity builds it was not - causing a compilation error. An inspection of the Boost code revealed that we can just gate the statements by `_MS_VER` instead. A `#pragma message` is added to verify that the statement is only printed on Windows builds.

* fix: uint128 ambiguousness breaking macos unity build (#5386)

* Fix to correct memory ordering for compare_exchange_weak and wait in the intrusive reference counting logic (#5381)

This change addresses a memory ordering assertion failure observed on one of the Windows test machines during the IntrusiveShared_test suite.

* fix: disable `channel_authorize` when `signing_support` is disabled (#5385)

* fix: Use the build image from ghcr.io (#5390)

The ci pipelines are constantly hitting Docker Hub's public rate limiting since increasing the number of jobs we're running. This change switches over to images hosted in GitHub's registry.

* Remove UNREACHABLE from `NetworkOPsImp::processTrustedProposal` (#5387)

It’s possible for this to happen legitimately if a set of peers, including a validator, are connected in a cycle, and the latency and message processing time between those peers is significantly less than the latency between the validator and the last peer. It’s unlikely in the real world, but obviously easy to simulate with Antithesis.

* Instrument proposal, validation and transaction messages (#5348)

Adds metric counters for the following P2P message types:

* Untrusted proposal and validation messages
* Duplicate proposal, validation and transaction messages

* refactor(trivial): reorganize ledger entry tests and helper functions (#5376)

This PR splits out `ledger_entry` tests into its own file (`LedgerEntry_test.cpp`) and alphabetizes the helper functions in `LedgerEntry.cpp`. These commits were split out of #5237 to make that PR a little more manageable, since these basic trivial changes are most of the diff. There is no code change, just moving code around.

* fix: `fixPayChanV1` (#4717)

This change introduces a new fix amendment (`fixPayChanV1`) that prevents the creation of new `PaymentChannelCreate` transaction with a `CancelAfter` time less than the current ledger time. It piggy backs off of fix1571.

Once the amendment is activated, creating a new `PaymentChannel` will require that if you specify the `CancelAfter` time/value, that value must be greater than or equal to the current ledger time.

Currently users can create a payment channel where the `CancelAfter` time is before the current ledger time. This results in the payment channel being immediately closed on the next PaymentChannel transaction.

* Fix: admin RPC webhook queue limit removal and timeout reduction (#5163)

When using subscribe at admin RPC port to send webhooks for the transaction stream to a backend, on large(r) ledgers the endpoint receives fewer HTTP POSTs with TX information than the amount of transactions in a ledger. This change removes the hardcoded queue length to avoid dropping TX notifications for the admin-only command. In addition, the per-request TTL for outgoing RPC HTTP calls has been reduced from 10 minutes to 30 seconds.

* fix: Adds CTID to RPC tx and updates error (#4738)

This change fixes a number of issues involved with CTID:
* CTID is not present on all RPC tx transactions.
* rpcWRONG_NETWORK is missing in the ErrorCodes.cpp

* Temporary disable automatic triggering macOS pipeline (#5397)

We temporarily disable running unit tests on macOS on the CI pipeline while we are investigating the delays.

* refactor: Clean up test logging to make it easier to search (#5396)

This PR replaces the word `failed` with `failure` in any test names and renames some test files to fix MSVC warnings, so that it is easier to search through the test output to find tests that failed.

* chore: Run CI on PRs that are Ready or have the "DraftRunCI" label (#5400)

- Avoids costly overhead for idle PRs where the CI results don't add any
  value.

* fix: CTID to use correct ledger_index (#5408)

* chore: Small clarification to lsfDefaultRipple comment (#5410)

* fix: Replaces random endpoint resolution with sequential (#5365)

This change addresses an issue where `rippled` attempts to connect to an IPv6 address, even when the local network lacks IPv6 support, resulting in a "Network is unreachable" error.

The fix replaces the custom endpoint selection logic with `boost::async_connect`, which sequentially attempts to connect to available endpoints until one succeeds or all fail.

* Improve transaction relay logic (#4985)

Combines four related changes:
1. "Decrease `shouldRelay` limit to 30s." Pretty self-explanatory. Currently, the limit is 5 minutes, by which point the `HashRouter` entry could have expired, making this transaction look brand new (and thus causing it to be relayed back to peers which have sent it to us recently).
2.  "Give a transaction more chances to be retried." Will put a transaction into `LedgerMaster`'s held transactions if the transaction gets a `ter`, `tel`, or `tef` result. Old behavior was just `ter`.
     * Additionally, to prevent a transaction from being repeatedly held indefinitely, it must meet some extra conditions. (Documented in a comment in the code.)
3. "Pop all transactions with sequential sequences, or tickets." When a transaction is processed successfully, currently, one held transaction for the same account (if any) will be popped out of the held transactions list, and queued up for the next transaction batch. This change pops all transactions for the account, but only if they have sequential sequences (for non-ticket transactions) or use a ticket. This issue was identified from interactions with @mtrippled's #4504, which was merged, but unfortunately reverted later by #4852. When the batches were spaced out, it could potentially take a very long time for a large number of held transactions for an account to get processed through. However, whether batched or not, this change will help get held transactions cleared out, particularly if a missing earlier transaction is what held them up.
4. "Process held transactions through existing NetworkOPs batching." In the current processing, at the end of each consensus round, all held transactions are directly applied to the open ledger, then the held list is reset. This bypasses all of the logic in `NetworkOPs::apply` which, among other things, broadcasts successful transactions to peers. This means that the transaction may not get broadcast to peers for a really long time (5 minutes in the current implementation, or 30 seconds with this first commit). If the node is a bottleneck (either due to network configuration, or because the transaction was submitted locally), the transaction may not be seen by any other nodes or validators before it expires or causes other problems.

* Enable passive squelching (#5358)

This change updates the squelching logic to accept squelch messages for untrusted validators. As a result, servers will also squelch untrusted validator messages reducing duplicate traffic they generate.

In particular:
* Updates squelch message handling logic to squelch messages for all validators, not only trusted ones.
* Updates the logic to send squelch messages to peers that don't squelch themselves
* Increases the threshold for the number of messages that a peer has to deliver to consider it as a candidate for validator messages.

* Add PermissionDelegation feature (#5354)

This change implements the account permission delegation described in XLS-75d, see XRPLF/XRPL-Standards#257.

* Introduces transaction-level and granular permissions that can be delegated to other accounts.
* Adds `DelegateSet` transaction to grant specified permissions to another account.
* Adds `ltDelegate` ledger object to maintain the permission list for delegating/delegated account pair.
* Adds an optional `Delegate` field in common fields, allowing a delegated account to send transactions on behalf of the delegating account within the granted permission scope. The `Account` field remains the delegating account; the `Delegate` field specifies the delegated account. The transaction is signed by the delegated account.

* refactor: use east const convention (#5409)

This change refactors the codebase to use the "east const convention", and adds a clang-format rule to follow this convention.

* fix: enable LedgerStateFix for delegation (#5427)

* Configure CODEOWNERS for changes to RPC code (#5266)

To ensure changes to any RPC-related code are compatible with other services, such as Clio, the RPC team will be required to review them.

* fix: Ensure that coverage file generation is atomic. (#5426)

Running unit tests in parallel and multiple threads can write into one file can corrupt output files, and then gcovr won't be able to parse the corrupted file. This change adds -fprofile-update=atomic as instructed by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68080.

* fix: Update validators-example.txt fix xrplf example URL (#5384)

* Fix: Resolve slow test on macOS pipeline (#5392)

Using std::barrier performs extremely poorly (~1 hour vs ~1 minute to run the test suite) in certain macOS environments.
To unblock our macOS CI pipeline, std::barrier has been replaced with a custom mutex-based barrier (Barrier) that significantly improves performance without compromising correctness.

* Set version to 2.5.0-b1

---------

Co-authored-by: Bart <bthomee@users.noreply.github.com>
Co-authored-by: Ed Hennis <ed@ripple.com>
Co-authored-by: Bronek Kozicki <brok@incorrekt.com>
Co-authored-by: Darius Tumas <Tokeiito@users.noreply.github.com>
Co-authored-by: Sergey Kuznetsov <skuznetsov@ripple.com>
Co-authored-by: cyan317 <120398799+cindyyan317@users.noreply.github.com>
Co-authored-by: Vlad <129996061+vvysokikh1@users.noreply.github.com>
Co-authored-by: Alex Kremer <akremer@ripple.com>
Co-authored-by: Valentin Balaschenko <13349202+vlntb@users.noreply.github.com>
Co-authored-by: Mayukha Vadari <mvadari@ripple.com>
Co-authored-by: Vito Tumas <5780819+Tapanito@users.noreply.github.com>
Co-authored-by: Denis Angell <dangell@transia.co>
Co-authored-by: Wietse Wind <w.wind@ipublications.net>
Co-authored-by: yinyiqian1 <yqian@ripple.com>
Co-authored-by: Jingchen <a1q123456@users.noreply.github.com>
Co-authored-by: brettmollin <brettmollin@users.noreply.github.com>
This was referenced Jun 12, 2025
@legleux legleux mentioned this pull request Jun 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ready to merge *PR author* thinks it's ready to merge. Has passed code review. Perf sign-off may still be required.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0