[LILA-7980] Do not throw on zero fee returned #59
Conversation
There can be edge cases in the pool where the pool may provide one or more wei in the calculation functions and the calculation functions return zero. For example, this can happen when CHAR is using a new feature called `minimumTCLSeedingThreshold` that: 1. avoids charging fees to deposits that keep the total underlying supply below a certain threshold 2. charges fees partially when the deposit brings the total underlying supply above the threshold 3. charges fees normally above the threshold Given a deposit that falls under 2, it may be that the chargeable amount is one or more few wei. In this scenario, the pool currently has to handle an error returned by the fee calculator which decreases devexp and complicates pool code. On the other hand, the pool code is already written to loop through the returned arrays that are part of the FeeDistribution struct so returning a struct with empty arrays means this edge case can be handled in the pool seamlessly.
Maybe @kosecki123 @PawelTroka can help answer since they authored it? My guess is that there was no use of an empty response before, whereas failing was easier to catch and identify these cases where fee can be zero. |
|
No, I mean I couldn't see where it throws in this case. Perhaps I should have been looking outside the code affected by the PR? |
It used to throw in L209. This can happen when the caller provides a very small amount that can cause the fee calculation to result in zero. A few test cases were changed that exemplified the revert, eg. this one used 1 wei as a deposit amount which cannot be divided further. All that being said, I think we probably need to revert, see Slack for more info. See also this PR (this CI run specifically with a new integration test added to fail because of this exact edge case). |
|
Reverting in #60 |
There can be edge cases in the pool where the pool may provide one or more wei in the calculation
functions and the calculation functions return zero.
For example, this can happen when CHAR is using a
new feature called
minimumTCLSeedingThresholdthat:Given a deposit that falls under 2, it may be that the chargeable amount is one or more few wei. In this scenario, the pool currently has to handle an error returned by the fee calculator which decreases devexp and complicates pool code.
On the other hand, the pool code is already written to loop through the returned arrays that are part of the FeeDistribution struct so returning a struct with empty arrays means this edge case can be handled in the pool seamlessly.