Skip to content
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

Feature/fix perpetual futures net position of market #480

Merged
merged 12 commits into from
Apr 10, 2023

Conversation

taiki1frsh
Copy link
Collaborator

@taiki1frsh taiki1frsh commented Apr 10, 2023

close #479

Besides, implemented ClosePosition unit test

@taiki1frsh taiki1frsh marked this pull request as ready for review April 10, 2023 08:57
@taiki1frsh taiki1frsh requested a review from kimurayu45z April 10, 2023 08:57
PositionType position_type = 2 [
(gogoproto.moretags) = "yaml:\"position_type\""
];
string position_size_in_denom_unit = 3 [
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it difficult to make this PositionSize as sdk.Dec?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No,
should it be sdk.Dec?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

But, it's treated as sdk.Int inside

Copy link
Contributor

Choose a reason for hiding this comment

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

Interface that is exposed to API users should be treated as well as other places. PositionSize is treated in Dec in Msg for example so should follow it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

no, this type is not exposed as API at this moment

Copy link
Contributor

Choose a reason for hiding this comment

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

If so, it is ok to use Int.

just denom_exponent is better I think instead of denom_unit

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, it makes sense.
I will modify and merge this.

@@ -1695,7 +1695,8 @@ Query defines the gRPC querier service.
| Field | Type | Label | Description |
| ----- | ---- | ----- | ----------- |
| `market` | [Market](#ununifi.derivatives.Market) | | |
| `position_size_in_micro` | [string](#string) | | |
| `position_type` | [PositionType](#ununifi.derivatives.PositionType) | | |
| `position_size_in_denom_exponent` | [string](#string) | | |



Copy link

Choose a reason for hiding this comment

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

with a brief code review:

This patch looks like it is adding a new field called position_type and replacing the existing position_size_in_micro field with position_size_in_denom_exponent. Both of these fields are of type PositionType and string respectively. No bugs appear to be present in the patch, however it is recommended to ensure that the new field is properly initialized and the data types are correct. Additionally, documentation should be added if necessary to explain what the fields represent and how they will be used.

(gogoproto.moretags) = "yaml:\"position_type\""
];
string position_size_in_denom_exponent = 3 [
(gogoproto.moretags) = "yaml:\"position_size_in_denom_exponent\"",
(gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Int",
(gogoproto.nullable) = false
];
Copy link

Choose a reason for hiding this comment

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

The code patch looks good, however there are a few issues that could be improved upon. Firstly, the variable names should be more descriptive. For example, the variable "position_size_in_micro" should be "position_size_in_denom_exponent". Secondly, the variable names should be consistent with the rest of the codebase. Thirdly, there should be comments to explain what each variable is used for and how it is calculated. Finally, the code should be tested thoroughly to ensure that all changes work as expected.

PositionSizeInMicro: position_size_in_micro,
Market: market,
PositionType: positionType,
PositionSizeInDenomExponent: position_size_in_denom_exponent,
}
}

Copy link

Choose a reason for hiding this comment

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

with the code review:

The code looks good and there are no obvious bugs. The main improvement that I suggest is to add more comments to explain why the code is written in a certain way. This can help others understand the code better and also make maintenance easier. In addition, it would be beneficial to add unit tests to ensure that the code works as expected.

@@ -1695,7 +1695,8 @@ Query defines the gRPC querier service.
| Field | Type | Label | Description |
| ----- | ---- | ----- | ----------- |
| `market` | [Market](#ununifi.derivatives.Market) | | |
| `position_size_in_micro` | [string](#string) | | |
| `position_type` | [PositionType](#ununifi.derivatives.PositionType) | | |
| `position_size_in_denom_exponent` | [string](#string) | | |



Choose a reason for hiding this comment

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

The code patch changes the Query gRPC service by adding two fields: position_type of type PositionType and position_size_in_denom_exponent of type string.

Based on the information provided, it is not possible to identify any bug risks in this code patch. However, some suggestions for improvement are:

  • Providing more information about the purpose and usage of the new fields can help with understanding the changes made to the Query service.
  • Adding validation logic for the input values of position_size_in_denom_exponent can improve the reliability and security of the code.

(gogoproto.moretags) = "yaml:\"position_type\""
];
string position_size_in_denom_exponent = 3 [
(gogoproto.moretags) = "yaml:\"position_size_in_denom_exponent\"",
(gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Int",
(gogoproto.nullable) = false
];

Choose a reason for hiding this comment

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

The code patch seems to be adding two new fields to the PerpetualFuturesNetPositionOfMarket message.

The first field is a position_type of type PositionType. It has a YAML tag "yaml:\"position_type\"". The PositionType type should be defined elsewhere in the codebase, and it would be helpful to have more information about what values it can take.

The second field is position_size_in_denom_exponent of type string. It has a YAML tag "yaml:\"position_size_in_denom_exponent\"". This field also has additional Go protocol buffer tags, including "github.com/cosmos/cosmos-sdk/types.Int" for the custom type definition and "(gogoproto.nullable) = false" to ensure that the value is not nullable. However, the name of the field is somewhat unclear, as it suggests that the value is an exponent but it is stored as a string. Some additional clarification or documentation on this field would be helpful.

Without further information about the rest of the codebase and its functionality, it is difficult to identify specific risk areas or improvement suggestions.

PositionSizeInMicro: position_size_in_micro,
Market: market,
PositionType: positionType,
PositionSizeInDenomExponent: position_size_in_denom_exponent,
}
}

Choose a reason for hiding this comment

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

The code changes seem fine overall.

One suggestion would be to add input validation for the NewPerpetualFuturesNetPositionOfMarket function, especially for the position_size_in_denom_exponent argument since it is now taking user-input in denomination unit. Additionally, you could add comments or documentation about what PositionType entails and how it should be used in this function.

Another point to consider is whether the PositionType field can capture all the necessary information needed for a perpetual futures position. If you find that more information is needed, you might want to consider adding additional fields to this struct.

Overall, there don't appear to be any major bug risks in this code patch.

@taiki1frsh taiki1frsh merged commit 363fbc3 into newDevelop Apr 10, 2023
@taiki1frsh taiki1frsh deleted the feature/fix-PerpetualFuturesNetPositionOfMarket branch April 10, 2023 09:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[derivatives] Handle PerpetualFuturesNetPositionOfMarket properly to reflect the both long/short positions
2 participants