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

Improve update_position API and position execution events. #4121

Merged
merged 4 commits into from
Mar 27, 2024

Conversation

hdevalence
Copy link
Member

This commit changes update_position so that the caller is responsible for
fetching the previous state and then passing it in. While this adds misuse
potential into the API, the method is only used by the PositionManager and it
allows the high-level modification methods to do their own invariant checks
without blocking on extra reads.

This commit improves event handling for PositionExecution:

  • we add the previous balances to the event
  • we add a context to the event that allows connecting the micro-scale execution with a high-level context
  • we fix a bug where events were emitted multiple times
  • we avoid emitting events for no-op executions.

I believe that both of these changes are not state-breaking or consensus-breaking but would appreciate review of that.

Closes #3844 (cc @philipjames44)

This commit changes `update_position` so that the caller is responsible for
fetching the previous state and then passing it in. While this adds misuse
potential into the API, the method is only used by the `PositionManager` and it
allows the high-level modification methods to do their own invariant checks
without blocking on extra reads.
This commit improves event handling for PositionExecution:

- we add the previous balances to the event
- we add a `context` to the event that allows connecting the micro-scale execution with a high-level context
- we fix a bug where events were emitted multiple times
- we avoid emitting events for no-op executions.
Copy link
Member

@erwanor erwanor left a comment

Choose a reason for hiding this comment

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

ACK / I left some smaller suggestions take it or leave it. I'm convinced this is correct and not consensus breaking.

}

// Update the available liquidity for this position's trading pair.
self.update_available_liquidity(&position, &prev).await?;
self.update_available_liquidity(&new_state, &prev_state)
Copy link
Member

Choose a reason for hiding this comment

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

This PR actually improves on the previous impl because prev_state is Option<Position> but noting that the parent method signature is:

async fn update_position(
         &mut self,
         prev_state: Option<Position>,
         new_state: Position,
    ) -> Result<()>;

And this method is:

async fn update_available_liquidity(
        &mut self,
        position: &Position,
        prev_position: &Option<Position>,
    ) -> Result<()>;

but since the types are different this is probably fine

Copy link
Member Author

Choose a reason for hiding this comment

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

I'd rather streamline that code in a later PR that implements eviction, but good spotting. Added a TODO.

@hdevalence hdevalence merged commit 9c3bc98 into main Mar 27, 2024
7 checks passed
@hdevalence hdevalence deleted the improve-updateposition branch March 27, 2024 22:31
@erwanor erwanor added the A-dex Area: Relates to the dex label Apr 5, 2024
@erwanor erwanor added this to the Sprint 3 milestone Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dex Area: Relates to the dex
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

dex: change EventPositionExecution to have old reserves as well as new ones
2 participants