Deep freeze (#5187) #5187

vvysokikh1 · 2024-11-11T20:27:42Z

High Level Overview of Change

This PR implements Deep Freeze feature described in this specification: XLS-77d

Context of Change

Added new flags and functionality allowing trust lines to be deep-frozen.

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Refactor (non-breaking change that only restructures code)
Performance (increase or change in throughput and/or latency)
Tests (you added tests for code that already exists, or your new feature included in this PR)
Documentation update
Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
Release

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)

Specification: XRPLF/XRPL-Standards#220

to accepting the amendment.

src/xrpld/app/paths/detail/StepChecks.h

src/xrpld/app/tx/detail/SetTrust.cpp

src/xrpld/ledger/detail/View.cpp

ximinez

Partial review. I didn't go through all the tests.

src/xrpld/app/tx/detail/CreateOffer.cpp

src/xrpld/app/tx/detail/SetTrust.cpp

src/xrpld/ledger/detail/View.cpp

src/xrpld/app/tx/detail/SetTrust.cpp

ximinez

Partial review

src/xrpld/app/paths/detail/StepChecks.h

src/xrpld/app/tx/detail/SetTrust.cpp

Co-authored-by: Ed Hennis <ed@ripple.com>

include/xrpl/protocol/LedgerFormats.h

src/xrpld/app/tx/detail/SetTrust.cpp

include/xrpl/protocol/detail/features.macro

src/xrpld/ledger/detail/View.cpp

src/test/app/AMMExtended_test.cpp

gregtatcam · 2024-12-05T14:26:41Z

src/test/app/AMM_test.cpp

@@ -4397,6 +4397,48 @@ struct AMM_test : public jtx::AMMTest
            0,
            std::nullopt,
            {features});
+
+        // Individually deep frozen account
+        if (features[featureDeepFreeze])


Don't need to repeat the code. Just add a conditional error:

auto const err = features[featureDeepFreeze] ? ter(tecPATH_DRY) : ter(tesSUCCESS)

And then use it in pay:

env(pay(alice, carol, USD(1)), path(~USD), sendmax(XRP(10)), txflags(tfNoRippleDirect | tfPartialPayment), err);

Actually, you shouldn't test here and other updated unit-tests if the feature is disabled because trust is going to fail. You need a separate test for disabled feature in SetTrust and also add to SetTrust tests for invalid combination of the flags. Also need to add OfferCreate and offer crossing, if not added yet, to Offer.

src/test/app/AMMExtended_test.cpp

src/xrpld/app/tx/detail/SetTrust.cpp

src/xrpld/app/paths/detail/StepChecks.h

src/xrpld/app/tx/detail/SetTrust.cpp

vvysokikh1 · 2025-01-17T17:00:37Z

Build fails in Freeze_test.cpp with a number of errors:
src/test/app/Freeze_test.cpp:1462:17: error: reference to ‘path’ is ambiguous 1462 | path(~USD),

Weird, builds and runs on my end. What's your environment?

MAC M1 Sequoia 15.1.1, Apple clang version 16.0.0 (clang-1600.0.26.4) Linux g++ (Ubuntu 13.1.0-8ubuntu1~22.04) 13.1.0

I'm on M3 Sequoia 15.2, same clang version

The issue is related to unity build, working on a fix

codecov · 2025-01-17T17:53:45Z

Codecov Report

Attention: Patch coverage is 57.20524% with 98 lines in your changes missing coverage. Please review.

Project coverage is 77.9%. Comparing base (ebd8e63) to head (c1778e5).
Report is 2 commits behind head on develop.

Files with missing lines	Patch %	Lines
src/xrpld/app/tx/detail/InvariantCheck.cpp	13.9%	93 Missing ⚠️
src/xrpld/app/tx/detail/NFTokenAcceptOffer.cpp	84.0%	4 Missing ⚠️
src/xrpld/app/tx/detail/CreateOffer.cpp	87.5%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #5187     +/-   ##
=========================================
- Coverage     78.0%   77.9%   -0.1%     
=========================================
  Files          789     789             
  Lines        66955   67164    +209     
  Branches      8132    8166     +34     
=========================================
+ Hits         52223   52325    +102     
- Misses       14732   14839    +107

Files with missing lines	Coverage Δ
include/xrpl/protocol/Feature.h	`100.0% <ø> (ø)`
src/xrpld/app/paths/TrustLine.h	`100.0% <100.0%> (ø)`
src/xrpld/app/paths/detail/StepChecks.h	`100.0% <100.0%> (ø)`
src/xrpld/app/tx/detail/CashCheck.cpp	`87.9% <ø> (ø)`
src/xrpld/app/tx/detail/InvariantCheck.h	`100.0% <ø> (ø)`
src/xrpld/app/tx/detail/NFTokenAcceptOffer.h	`100.0% <ø> (ø)`
src/xrpld/app/tx/detail/OfferStream.cpp	`81.6% <100.0%> (+1.3%)`	⬆️
src/xrpld/app/tx/detail/SetTrust.cpp	`90.9% <100.0%> (+1.3%)`	⬆️
src/xrpld/ledger/View.h	`100.0% <ø> (ø)`
src/xrpld/ledger/detail/View.cpp	`91.3% <100.0%> (+0.2%)`	⬆️
... and 4 more

... and 4 files with indirect coverage changes

src/test/app/Freeze_test.cpp

shawnxie999 · 2025-01-22T16:20:00Z

src/test/app/Freeze_test.cpp

@@ -1778,6 +1781,151 @@ class Freeze_test : public beast::unit_test::suite
        }
    }

+    void
+    testNFTOffersWhenFreeze(FeatureBitset features)


these tests only exercise when someone accepts a sell offer from the owner. have we considered adding tests where the NFT owner accepts a buy offer? (where the potential buyer is deep frozen)

if buyer is deep frozen, he's normally frozen. His accountHolds check will not let this transaction through. Such tests exist in nft tests.

i thought of another scenario:

alice mints NFT

alice creates a sell offer using USD

bob creates a buy offer using USD

carol (broker) accepts the two offers and earns some USD (if buy offer amount is higher than sell offer, broker has the oppportunity to earn buy offer amt - sell offer amt) You can find unit tests by searching for brokerOffers.

we would need to make sure that at step 4, carol cannot broker the offers if she is deep frozen

src/xrpld/app/tx/detail/NFTokenAcceptOffer.cpp

src/test/app/Freeze_test.cpp

ximinez · 2025-01-22T23:48:09Z

src/test/app/Freeze_test.cpp

+            // test: this should actually fail since the currency holder doesn't
+            // want to receive this currency.
+            env(token::acceptSellOffer(A1, sellOfferIndex));
+            env.close();


This comment is incorrect. A2 has indicated that they want to receive the currency by creating the offer. Any affirmative action by the account receiving funds can override the "limit" set on the trust line, or create a trust line if one doesn't exist. The same is true of offers on the DEX.

We had this case discussed during last call. It's a part of 'missing checks if account is allowed to receive currency'. I'm not convinced this is correct behavior, normal offers behave differently. Also I see the use-case where currency holder would want to freeze the trustline to stop inflow of certain currency instead of cancelling all existing nft offers.

The only exception here would actually be acceptance of check, which is really an indication of acceptance. But even this is not currently possible.

src/test/ledger/Invariants_test.cpp

src/test/rpc/AccountLines_test.cpp

gregtatcam · 2025-01-17T20:02:33Z

src/xrpld/ledger/detail/View.cpp

+        if (zeroIfFrozen == fhZERO_IF_FROZEN)
+        {
+            if (isFrozen(view, account, currency, issuer) ||
+                isDeepFrozen(view, account, currency, issuer))


I'm curious, why not keep the original code and just add || isDeepFrozen?

else if ( (zeroIfFrozen == fhZERO_IF_FROZEN) && (isFrozen(view, account, currency, issuer) || isDeepFrozen(view, account, currency, issuer)))

Unless there is a good reason to change, IMO fewer changes is less risk and easier to review.

I just couldn't help myself to change the previous version.

I don't see much benefit in this change. It's one line change vs. a bunch of changes. But it's just my opinion.

I find it a bit easier to understand and read, that's the only reason for this change. I can roll back if you insist. I has good test coverage though, so I don't find it risky

src/xrpld/app/tx/detail/NFTokenAcceptOffer.cpp

gregtatcam · 2025-01-21T12:12:22Z

src/xrpld/app/tx/detail/CreateOffer.cpp

+    auto const trustLine =
+        view.read(keylet::line(id, issue.account, issue.currency));
+
+    if (!trustLine)


Why returning tesSUCCESS? Shouldn't this be similar to a few lines above:

if (!trustLine) { return (flags & tapRETRY) ? TER{terNO_LINE} : TER{tecNO_LINE}; }

If returning an error then the code also has to be amendment gated.

Here it's simply checking if trust line exists. If it doesn't exist, there's no freeze/deep freeze flags there so we just exit

gregtatcam · 2025-01-21T21:01:10Z

src/test/app/Freeze_test.cpp

+            env.close();
+
+            // test: A1 can send XRP using USD through A2 offer
+            // TODO: This might be not a correct behavior. A2 doesn't want to


When holder freezes trust line, his intention is to avoid receiving this token. So it might be incorrect behavior because in this case he actually receives those.

gregtatcam · 2025-01-21T21:01:17Z

src/test/app/Freeze_test.cpp

+            env.close();
+
+            // test: G1 cannot send XRP using USD through A2 offer
+            // TODO: This might be not a correct behavior. A2 doesn't want to


src/test/app/Freeze_test.cpp

gregtatcam · 2025-01-23T18:41:40Z

src/test/app/Freeze_test.cpp

+    }
+
+    void
+    testLongerPathsWhenFrozen(FeatureBitset features)


Why "LongerPaths"? It's the same number of steps, just a payment is used instead of an offer.

Why is it the same number? These tests have book step and xrp step at the very least?

With the offer crossing tests you are exchanging XRP for USD or USD for XRP. Payment does the same thing. The payment engine steps are slightly different. In case of the offer crossing the steps are:

XRPEndpointOfferCrossingStep BookOfferCrossingStep DirectIOfferCrossingStep

and in case of the payment the steps are:

XRPEndpointPaymentStep BookPaymentStep DirectIPaymentStep

A longer path is something like this: exchange XRP for USD and then exchange USD for GBP as part of the same payment. Or as a unit test something like this:

env(pay(carol, bob, USD(1)), test::jtx::path(~USD, ~GBP), sendmax(XRP(1)), txflags(tfNoRippleDirect));

src/test/app/Freeze_test.cpp

ckeshava · 2025-01-24T05:56:18Z

src/test/rpc/AccountLines_test.cpp

@@ -981,7 +987,11 @@ class AccountLines_test : public beast::unit_test::suite
            env.close();

            // Set flags on gw2 trust lines so we can look for them.
-            env(trust(alice, gw2Currency(0), gw2, tfSetNoRipple | tfSetFreeze));
+            env(trust(


What is the difference between this test and the one above? (Both of them are prefaced by the same comment // Set flags on gw2 trust lines so we can look for them.)
Are any of the pre-conditions different in these tests?

different RPC formats seem to be the difference

src/test/rpc/AccountLines_test.cpp

src/xrpld/app/tx/detail/InvariantCheck.h

ckeshava · 2025-01-24T06:05:03Z

src/xrpld/app/tx/detail/InvariantCheck.h

+};
+
+/**
+ * @brief Invariant: frozen trust line balance change is not allowed.


A normal frozen trust line could increase its balance (another counter-party could send IOUs to increase the frozen account's balance). Is this a different case?

Are there unit tests which exercise this invariant?

working on them at the moment.

src/xrpld/app/tx/detail/NFTokenAcceptOffer.cpp

ckeshava · 2025-01-24T06:36:07Z

src/xrpld/rpc/handlers/AccountLines.cpp

@@ -62,6 +62,10 @@ addLine(Json::Value& jsonLines, RPCTrustLine const& line)
        jPeer[jss::freeze] = true;


Does the ledger_entry RPC command return deep_freeze flags (provided, it is set appropriately on the trust line) ? Can you add unit tests for the same?

I am referring to retrieval of trust-line ledger objects using the ledger_entry RPC

ledger_entry doesn't return anything related to trustline flags, so in a nutshell, it doesn't return information about either normal freeze or deep freeze.

ledger_entry does return a Flags field in the response. But it does not explicitly specify a boolean value for the deep_freeze field (unlike the account_lines rpc)

Here is an example: https://xrpl.org/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Fs1.ripple.com%2F&req=%7B%20%20%22id%22%3A%20%22example_get_ripplestate%22%2C%0A%20%20%22command%22%3A%20%22ledger_entry%22%2C%0A%20%20%22ripple_state%22%3A%20%7B%0A%20%20%20%20%22accounts%22%3A%20%5B%0A%20%20%20%20%20%20%22rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn%22%2C%0A%20%20%20%20%20%20%22rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW%22%0A%20%20%20%20%5D%2C%0A%20%20%20%20%22currency%22%3A%20%22USD%22%0A%20%20%7D%2C%0A%20%20%22ledger_index%22%3A%20%22validated%22%0A%7D

Perhaps, it does not warrant a unit test. I'll leave that up to your discretion.

Oh I see. I probably looked into wrong implementation.

But anyway, since raw flags are provided, there's no reason to add deep_freeze flag specific test in my opinion.

ximinez · 2025-01-24T17:32:38Z

src/xrpld/app/tx/detail/InvariantCheck.cpp

+    XRPL_ASSERT(
+        after, "ripple::BalanceChangeNotFrozen::visitEntry : invalid after.");


The name is supposed to indicate what you're testing, not what failed.

Suggested change

XRPL_ASSERT(

after, "ripple::BalanceChangeNotFrozen::visitEntry : invalid after.");

XRPL_ASSERT(

after, "ripple::BalanceChangeNotFrozen::visitEntry : valid after.");

ximinez · 2025-01-24T17:42:00Z

src/xrpld/app/tx/detail/InvariantCheck.cpp

+        STAmount amt =
+            line ? line->at(sfBalance) : line->at(sfBalance).zeroed();


Suggested change

STAmount amt =

line ? line->at(sfBalance) : line->at(sfBalance).zeroed();

STAmount amt =

line ? line->at(sfBalance) : other->at(sfBalance).zeroed();

ximinez · 2025-01-24T17:43:30Z

src/xrpld/app/tx/detail/InvariantCheck.cpp

+    XRPL_ASSERT(
+        change.balanceChangeSign,
+        "ripple::BalanceChangeNotFrozen::recordBalance : invalid trust "
+        "line balance sign.");


Suggested change

XRPL_ASSERT(

change.balanceChangeSign,

"ripple::BalanceChangeNotFrozen::recordBalance : invalid trust "

"line balance sign.");

XRPL_ASSERT(

change.balanceChangeSign,

"ripple::BalanceChangeNotFrozen::recordBalance : valid trust "

"line balance sign.");

ximinez · 2025-01-24T17:47:09Z

src/xrpld/app/tx/detail/InvariantCheck.cpp

+    recordBalance(
+        after->at(sfHighLimit).getIssuer(),
+        currency,
+        {after, balanceChangeSign});
+
+    recordBalance(
+        after->at(sfLowLimit).getIssuer(),
+        currency,
+        {after, -balanceChangeSign});


High and low sign handling is a consistent source of confusion. Some comments here would be helpful. Something like:

Suggested change

recordBalance(

after->at(sfHighLimit).getIssuer(),

currency,

{after, balanceChangeSign});

recordBalance(

after->at(sfLowLimit).getIssuer(),

currency,

{after, -balanceChangeSign});

// Change from low account's perspective, which is trust line default

recordBalance(

after->at(sfHighLimit).getIssuer(),

currency,

{after, balanceChangeSign});

// Change from high account's perspective, which reverses the sign.

recordBalance(

after->at(sfLowLimit).getIssuer(),

currency,

{after, -balanceChangeSign});

ximinez · 2025-01-24T17:53:16Z

src/xrpld/app/tx/detail/InvariantCheck.cpp

+    XRPL_ASSERT(
+        enforce,
+        "ripple::BalanceChangeNotFrozen::validateFrozenState : Attempting to "
+        "move frozen funds.");


Suggested change

XRPL_ASSERT(

enforce,

"ripple::BalanceChangeNotFrozen::validateFrozenState : Attempting to "

"move frozen funds.");

XRPL_ASSERT(

enforce,

"ripple::BalanceChangeNotFrozen::validateFrozenState : enforce invariant.");

ximinez · 2025-01-24T17:53:59Z

src/xrpld/app/tx/detail/InvariantCheck.cpp

+            XRPL_ASSERT(
+                enforce,
+                "ripple::BalanceChangeNotFrozen::finalize : Issuer not found.");


Suggested change

XRPL_ASSERT(

enforce,

"ripple::BalanceChangeNotFrozen::finalize : Issuer not found.");

XRPL_ASSERT(

enforce,

"ripple::BalanceChangeNotFrozen::finalize : enforce invariant.");

src/xrpld/app/tx/detail/NFTokenAcceptOffer.cpp

ximinez · 2025-01-24T18:03:13Z

src/xrpld/app/tx/detail/NFTokenAcceptOffer.cpp

+    XRPL_ASSERT(
+        !isXRP(issue.currency),
+        "NFTokenAcceptOffer::checkAcceptAsset : input is not XRP");


Suggested change

XRPL_ASSERT(

!isXRP(issue.currency),

"NFTokenAcceptOffer::checkAcceptAsset : input is not XRP");

XRPL_ASSERT(

!isXRP(issue.currency) && view.rules().enabled(featureDeepFreeze) ,

"NFTokenAcceptOffer::checkAcceptAsset : valid to check");

HowardHinnant added 3 commits October 30, 2024 12:36

Implement Deep Freeze

e57d068

Specification: XRPLF/XRPL-Standards#220

[FOLD] Move feature to top of list

a0d48ae

[FOLD] Make use of the deep freeze flags malformed prior

4aac190

to accepting the amendment.

vvysokikh1 requested review from bthomee, shawnxie999 and ximinez November 11, 2024 20:27

bthomee reviewed Nov 14, 2024

View reviewed changes

src/xrpld/app/paths/detail/StepChecks.h Outdated Show resolved Hide resolved

bthomee reviewed Nov 14, 2024

View reviewed changes

src/xrpld/app/tx/detail/SetTrust.cpp Outdated Show resolved Hide resolved

bthomee reviewed Nov 14, 2024

View reviewed changes

src/xrpld/ledger/detail/View.cpp Outdated Show resolved Hide resolved

Fixed creation of buy offer transaction to fail with tecFROZEN instantly

306a112

ximinez requested changes Nov 16, 2024

View reviewed changes

vvysokikh1 added 4 commits November 18, 2024 18:59

Fixed comments #1

f5efa31

Reworked freeze flag handling in SetTrust

8e1977f

Moved modified trustline flags extraction into separate function

a162663

Added more check to test cases

c7c26ac

vvysokikh1 force-pushed the deep_freeze branch from 9421c37 to c7c26ac Compare November 21, 2024 11:43

vvysokikh1 added 2 commits November 22, 2024 14:19

Added payment tests for freeze and deep freeze

805102a

Clarified behavior of individual freeze

de58a26

vvysokikh1 force-pushed the deep_freeze branch from ba87028 to de58a26 Compare November 22, 2024 17:58

vvysokikh1 added 2 commits November 28, 2024 16:46

Added offer test for freeze and deep freeze

91d291a

More offer tests

e0d59ef

ximinez requested changes Dec 4, 2024

View reviewed changes

src/xrpld/app/paths/detail/StepChecks.h Outdated Show resolved Hide resolved

src/xrpld/app/tx/detail/SetTrust.cpp Outdated Show resolved Hide resolved

src/xrpld/app/tx/detail/SetTrust.cpp Outdated Show resolved Hide resolved

vvysokikh1 and others added 3 commits December 4, 2024 10:21

Fixed typo

ffa6ccd

Co-authored-by: Ed Hennis <ed@ripple.com>

Fixed tx flags check in case trustline doesn't exist yet

f9107a7

Added tests for trustline creation freeze handling

1f9ecb8

gregtatcam reviewed Dec 5, 2024

View reviewed changes

vvysokikh1 added 3 commits December 6, 2024 15:10

Partially fixed comments

010f36d

Partially fixed comments

6bae95d

Fixed buy offer crossing when deep frozen

b5a10ec

vvysokikh1 changed the title ~~[WIP] Deep freeze~~ Deep freeze (#5187) Dec 10, 2024

Added longer path payment tests

ae5fae2

shawnxie999 reviewed Jan 17, 2025

View reviewed changes

src/xrpld/app/tx/detail/SetTrust.cpp Outdated Show resolved Hide resolved

vvysokikh1 added 4 commits January 17, 2025 15:37

Added NFT deep freeze tests

c60d491

Fixed flag

0d8855a

Merge branch 'develop' of github.com:vvysokikh1/rippled into deep_freeze

70235b6

Small fixes

a73ea01

vvysokikh1 added 3 commits January 17, 2025 17:08

Unity build fix

411a0f0

simplified unity build fix

4c5c9cc

Fixed tests

9f21f5d

vvysokikh1 added 5 commits January 20, 2025 14:27

Fixed NFT deep freeze offer acceptance

8c40ab9

Added invariant check for deep freeze flag on a trust line

c5aa145

Added deep freeze into acoount_lines rpc response

851e619

Uncommented NFT test with freeze on currency holder side

290b908

Added more invariant tests

9db6765

shawnxie999 reviewed Jan 22, 2025

View reviewed changes

src/xrpld/app/tx/detail/NFTokenAcceptOffer.cpp Outdated Show resolved Hide resolved

shawnxie999 requested changes Jan 22, 2025

View reviewed changes

src/xrpld/app/tx/detail/NFTokenAcceptOffer.cpp Show resolved Hide resolved

Comment fixes

7ba80fe

ximinez requested changes Jan 23, 2025

View reviewed changes

vvysokikh1 added 2 commits January 23, 2025 14:25

Comment fixes

79a4da3

Added invariant check for frozen trust line balance change

c1778e5

ximinez self-requested a review January 23, 2025 18:30

gregtatcam reviewed Jan 23, 2025

View reviewed changes

ckeshava reviewed Jan 24, 2025

View reviewed changes

XRPLF deleted a comment from ckeshava Jan 24, 2025

ximinez requested changes Jan 24, 2025

View reviewed changes

		@@ -62,6 +62,10 @@ addLine(Json::Value& jsonLines, RPCTrustLine const& line)
		jPeer[jss::freeze] = true;

		XRPL_ASSERT(
		after, "ripple::BalanceChangeNotFrozen::visitEntry : invalid after.");

		STAmount amt =
		line ? line->at(sfBalance) : line->at(sfBalance).zeroed();

Deep freeze (#5187) #5187

Are you sure you want to change the base?

Deep freeze (#5187) #5187

Conversation

vvysokikh1 commented Nov 11, 2024 • edited Loading

High Level Overview of Change

Context of Change

Type of Change

API Impact

ximinez left a comment

Choose a reason for hiding this comment

ximinez left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vvysokikh1 commented Jan 17, 2025

codecov bot commented Jan 17, 2025 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vvysokikh1 Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

vvysokikh1 Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vvysokikh1 Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vvysokikh1 Jan 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vvysokikh1 Jan 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vvysokikh1 commented Nov 11, 2024 •

edited

Loading

codecov bot commented Jan 17, 2025 •

edited

Loading

vvysokikh1 Jan 23, 2025 •

edited

Loading

vvysokikh1 Jan 23, 2025 •

edited

Loading

vvysokikh1 Jan 23, 2025 •

edited

Loading

vvysokikh1 Jan 24, 2025 •

edited

Loading

vvysokikh1 Jan 24, 2025 •

edited

Loading