[CT-629] Fix entryPrice calc #2455
Conversation
This reverts commit a282777.
WalkthroughThe pull request introduces modifications to the test suites for the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
indexer/services/ender/src/scripts/helpers/dydx_update_perpetual_position_aggregate_fields.sql (1)
Line range hint
1-78: Consider additional improvements and clarifications.While the main change has been addressed, here are some suggestions to enhance the overall function:
Error Handling: The function raises an exception when no existing perpetual position is found. Consider adding a more graceful error handling mechanism or documenting this behavior clearly in the function description.
Documentation: The function's description could be expanded to include information about the
dydx_get_weighted_average,dydx_trim_scale, anddydx_perpetual_position_and_order_side_matchingfunctions. This would provide better context for future maintainers.Performance: For frequently called functions, consider adding an index on (
subaccountId,perpetualId,openEventId) if not already present, to optimize the initial SELECT query.Could you provide more context on:
- The frequency of calls to this function?
- The typical volume of data it processes?
- Any performance benchmarks or requirements for this function?
This information would help in determining if any further optimizations are necessary.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
- indexer/services/ender/tests/handlers/order-fills/liquidation-handler.test.ts (2 hunks)
- indexer/services/ender/tests/handlers/order-fills/order-handler.test.ts (2 hunks)
- indexer/services/ender/src/scripts/helpers/dydx_liquidation_fill_handler_per_order.sql (1 hunks)
- indexer/services/ender/src/scripts/helpers/dydx_update_perpetual_position_aggregate_fields.sql (1 hunks)
🔇 Additional comments (7)
indexer/services/ender/src/scripts/helpers/dydx_update_perpetual_position_aggregate_fields.sql (1)
47-47: Approved: Entry price calculation reverted as intended.The change from
perpetual_position_record."sumOpen"toperpetual_position_record."size"in thedydx_get_weighted_averagefunction call aligns with the PR objective to revert the previous change in entry price calculation.To ensure the change doesn't introduce unintended consequences, please verify:
- The accuracy of entry price calculations, especially for positions that have been partially closed and reopened.
- The consistency of this change with other parts of the codebase that may rely on the entry price calculation.
Consider adding a comment explaining the rationale behind using
sizeinstead ofsumOpenfor future reference. For example:-- Using 'size' instead of 'sumOpen' for entry price calculation to accurately reflect the current position entry_price := dydx_get_weighted_average( perpetual_position_record."entryPrice", perpetual_position_record."size", price, size );indexer/services/ender/src/scripts/helpers/dydx_liquidation_fill_handler_per_order.sql (1)
203-203: Approved: Correction to entry price calculationThis change reverts the entry price calculation to use
perpetual_position_record."size"instead ofperpetual_position_record."sumOpen"when calculating the weighted average. This modification aligns with the PR objective and likely provides a more accurate representation of the current position size for the entry price calculation.The impact of this change:
- It corrects the entry price calculation, addressing the issue introduced in PR Revert "[CT-629] Fix entryPrice calc" #2425.
- The resulting
entry_pricewill now be based on the actual size of the position rather than the sum of open amounts.- This change ensures that the entry price more accurately reflects the current state of the perpetual position.
To ensure this change doesn't introduce any unintended side effects, please verify that:
- All other occurrences of
dydx_get_weighted_averagein the codebase use the correct size parameter.- The
perpetual_position_record."size"is always up-to-date and accurately represents the current position size.You can use the following script to check for other occurrences:
indexer/services/ender/__tests__/handlers/order-fills/liquidation-handler.test.ts (3)
140-141: Update in default perpetual position sizeThe
sizeproperty ofdefaultPerpetualPositionhas been changed from '10' to '5'. This change affects the initial state of the perpetual position used in tests.This change is likely intentional and may be part of adjusting test scenarios to match updated business logic or requirements.
395-397: Consistent updates to test expectationsThe test expectations for
sumOpenand other calculations have been updated to reflect the change in the initial position size. This ensures consistency with the modifieddefaultPerpetualPosition.These changes maintain the integrity of the test cases and accurately reflect the new initial conditions.
Line range hint
1-1180: Summary of changesThe primary change in this file is the update to the initial perpetual position size from '10' to '5'. This change has been consistently applied throughout the test cases, with appropriate adjustments to calculations and expectations. The core functionality and structure of the tests remain unchanged.
These changes appear to be intentional and well-implemented, maintaining the integrity and purpose of the test suite while adjusting for new initial conditions.
indexer/services/ender/__tests__/handlers/order-fills/order-handler.test.ts (2)
442-442: Approved: Consistent use ofsumOpenfor perpetual position calculationsThis change correctly updates the
expectPerpetualPositionfunction to usedefaultPerpetualPosition.sumOpeninstead ofdefaultPerpetualPosition.sizewhen calculating the expectedsumOpenvalue. This modification ensures consistency with the changes made to thedefaultPerpetualPositionobject and more accurately reflects the intended behavior of the perpetual position calculations.
141-142: Verify the relationship betweensizeandsumOpenThe
sizeproperty has been reduced from '10' to '5', but thesumOpenproperty remains at '10'. This results insumOpenbeing larger thansize, which might be intentional but could also be an oversight. Please verify if this is the desired behavior for thedefaultPerpetualPositionobject.✅ Verification successful
No inconsistency found between
sizeandsumOpenfordefaultPerpetualPosition.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for other occurrences of defaultPerpetualPosition to ensure consistency grep -rn "defaultPerpetualPosition" . | grep -v "__tests__"Length of output: 57
| @@ -200,7 +200,7 @@ BEGIN | |||
| perpetual_position_record."side", order_side) THEN | |||
| sum_open = dydx_trim_scale(perpetual_position_record."sumOpen" + fill_amount); | |||
| entry_price = dydx_get_weighted_average( | |||
| perpetual_position_record."entryPrice", perpetual_position_record."sumOpen", | |||
| perpetual_position_record."entryPrice", ABS(perpetual_position_record."size"), | |||
There was a problem hiding this comment.
nit: Possible to add a test-case where perpetual position size is = negative size of fill to test that the previous error case couldn't happen again?
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (1)
indexer/services/ender/__tests__/handlers/order-fills/order-handler.test.ts (1)
244-244: Document the newuseNegativeSizeparameterThe
useNegativeSizeparameter has been added to the test function. To enhance code clarity and maintainability, consider adding documentation or comments explaining the purpose and usage of this parameter.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- indexer/services/ender/tests/handlers/order-fills/order-handler.test.ts (6 hunks)
🧰 Additional context used
🔇 Additional comments (4)
indexer/services/ender/__tests__/handlers/order-fills/order-handler.test.ts (4)
141-141: Validate the impact of changingsizeto'5'indefaultPerpetualPositionThe
sizevalue indefaultPerpetualPositionhas been updated from'10'to'5'. Ensure that all tests and calculations depending on this value are adjusted accordingly to prevent unintended behavior.
215-215: Confirm the correctness of theuseNegativeSizeparameter in test casesThe boolean value
falsehas been added as a parameter. Verify that this aligns with the test's intended logic and thatuseNegativeSizeis correctly utilized within the test scenarios.
225-226: Ensure consistency in test parameter valuesThe addition of
falseas a parameter in these test cases may affect test outcomes. Please confirm that this change is intentional and that it accurately reflects the scenarios being tested.
458-458: VerifysumOpencalculation with potential negative sizesThe
sumOpenis updated usingdefaultPerpetualPosition.sumOpen!andtotalFilled. Ensure that whendefaultPerpetualPosition.sizeis negative, the calculation reflects the correct position size andsumOpenrepresents the accurate state of the position.
| [ | ||
| 'goodTilBlock', | ||
| { | ||
| goodTilBlock: 10, | ||
| }, | ||
| { | ||
| goodTilBlock: 15, | ||
| }, | ||
| true, |
There was a problem hiding this comment.
Review the new test case with useNegativeSize: true
A new test case has been introduced with useNegativeSize set to true. Verify that the system correctly handles negative sizes and that this test case effectively checks for the expected behavior when negative sizes are involved.
If negative sizes are not supported or could lead to errors, consider adding validation to prevent negative sizes or adjust the test case to reflect valid scenarios.
| PerpetualPositionTable.create({ | ||
| ...defaultPerpetualPosition, | ||
| size: useNegativeSize ? '-5' : defaultPerpetualPosition.size, | ||
| }), |
There was a problem hiding this comment.
Handle potential issues with negative size in PerpetualPositionTable.create
When useNegativeSize is true, the size is set to '-5'. Ensure that the system can handle negative position sizes without causing unexpected behavior or errors. If negative sizes are invalid, implement validation to prevent this assignment.
Consider applying this fix to validate the size before creation:
PerpetualPositionTable.create({
...defaultPerpetualPosition,
- size: useNegativeSize ? '-5' : defaultPerpetualPosition.size,
+ size: useNegativeSize && defaultPerpetualPosition.size.startsWith('-') ? defaultPerpetualPosition.size : defaultPerpetualPosition.size,
})Committable suggestion was skipped due to low confidence.
|
@Mergifyio backport release/indexer/v6.x |
|
@Mergifyio backport release/indexer/v7.x |
✅ Backports have been created
|
✅ Backports have been created
|
(cherry picked from commit c8f8a4a)
(cherry picked from commit c8f8a4a)
Co-authored-by: dydxwill <[email protected]>
Co-authored-by: dydxwill <[email protected]>
This reverts commit c8f8a4a.
Summary by CodeRabbit
Bug Fixes
LiquidationHandlerandOrderHandlerto reflect changes in thedefaultPerpetualPositionsize, ensuring accurate validation of liquidation orders and order fills.sumOpenand position size.Chores