equity-like-share values incorrect in market scenario with negative growth

[cdummett]

Problem encountered

Scenario 003 added in PR #6243 is failing equity-like-share calculations. Expected values are calculated from this sheet.

The scenario is designed to test the calculation of equity-like-share values in a market with negative growth. Most importantly, it checks the case where for some LPs, at the end of a market period, their growth scaled virtual-stake would be less than their physical-stake and therefore the virtual-stake is set to equal the physical-stake.

The above condition should cause the equity-like-share values to change at the end of a market period as not all LP virtual-stake values are scaled by the same factor.

Observed behaviour

Scenario is passing all checks until the 4th market period (the first period where the condition described above is encountered).

At the end of the 4th market period the following occurs:

• all virtual-stake values are correctly calculated.
• all equity-like-share values are unchanged (this is the incorrect behaviour).

Essentially it looks like equity-like-share values are not being recalculated at the end of a market period.

Expected behaviour

At the end of the 4th market period the following occurs:

• all virtual-stake values are correctly calculated.
• all equity-like-share values are updated (this is the correct behaviour).

Essentially it looks like equity-like-share values are not being recalculated at the end of a market period.

Steps to reproduce

Manual

Steps to reproduce the behaviour manually:

1. Checkout branch feat/shrinking_market_scenario in PR feat: Scenario 003 - market with periods of positive and negative growth #6243.
2. Run core/integration/features/verified/0042-LIQF-fees_rewards_growing_market.feature
3. See error

Automation

Link to automation and explanation on how to run it to reproduce the problem/bug

Evidence

Additional context

See this sheet for expected calculations

Definition of Done

ℹ️ Not every issue will need every item checked, however, every item on this list should be properly considered and actioned to meet the DoD.

Before Merging

• Code refactored to meet SOLID and other code design principles
• Code is compilation error, warning, and hint free
• Carry out a basic happy path end-to-end check of the new code
• All APIs are documented so auto-generated documentation is created
• All bug recreation steps can be followed without presenting the original error/bug
• All Unit, Integration and BVT tests are passing
• Implementation is peer reviewed (coding standards, meeting acceptance criteria, code/design quality)
• Create front end or console tickets with feature labels (should be done when starting the work if dependencies known i.e. API changes)

After Merging

• Move development ticket to Done if there is NO requirement for new system-tests
• Resolve any issues with broken system-tests
• Create documentation tickets with feature labels if functionality has changed, or is a new feature