Skip to content

Remove position wrapper methods from Pool#157

Merged
jordanschalm merged 6 commits intomainfrom
jord/position-refactoring
Feb 12, 2026
Merged

Remove position wrapper methods from Pool#157
jordanschalm merged 6 commits intomainfrom
jord/position-refactoring

Conversation

@jordanschalm
Copy link
Copy Markdown
Member

@jordanschalm jordanschalm commented Feb 11, 2026

This PR consolidates position health getters/setters and sink/source methods by having Position access InternalPosition directly via a new EPosition-scoped borrowPosition method, removing 8 thin pass-through methods from Pool. Previously there were 3 layers of functions for many position-related operations, that all did the same thing: this PR removes the middle layer where possible.

This PR also adds constraints to Position.minHealth to enforce that it is always >1. This has the side effect of fixing an edge case where a user could withdraw from an unhealthy position by manipulating minHealth (this branch contains a test demonstrating the scenario).

  • Move all validation into InternalPosition setters (setMinHealth, setMaxHealth, setTargetHealth) so it lives in one place at the lowest level
  • Add EPosition-scoped lock/unlock to Pool for use by Position resources
  • Rewrite Position health getters/setters and provideSink/provideSource to use borrowPosition directly

jordanschalm and others added 5 commits February 11, 2026 11:40
Consolidate position health getters/setters and sink/source methods
by having Position (layer 3) access InternalPosition directly via a
new EPosition-scoped borrowPosition method, removing 8 thin
pass-through methods from Pool (layer 2).

- Move validation into InternalPosition setters (setMinHealth,
  setMaxHealth, setTargetHealth) so it lives in one place
- Fix setMaxHealth precondition bug: was >= 1.0, now
  >= self.targetHealth (matching its error message)
- Add EPosition-scoped borrowPosition, lockPosition, unlockPosition
  to Pool for use by Position resources
- Rewrite Position health getters/setters and provideSink/provideSource
  to use borrowPosition directly

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Test that setMinHealth rejects values below 1.0
- Test that withdrawals are rejected when they would drop health below 1.0

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- setMinHealth rejects values above targetHealth
- setTargetHealth rejects values at or below minHealth
- setTargetHealth rejects values at or above maxHealth
- setMaxHealth rejects values below targetHealth

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Move set_min_health, set_target_health, set_max_health from
test transactions to cadence/transactions/flow-alp/position/
and remove test-only warnings.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@jordanschalm jordanschalm changed the title Remove layer 2 position wrapper methods from Pool Remove position wrapper methods from Pool Feb 11, 2026
@jordanschalm jordanschalm marked this pull request as ready for review February 11, 2026 20:47
@jordanschalm jordanschalm requested a review from a team as a code owner February 11, 2026 20:47
Comment on lines +534 to +535
targetHealth > self.minHealth: "Target health (\(targetHealth)) must be greater than min health (\(self.minHealth))"
targetHealth < self.maxHealth: "Target health (\(targetHealth)) must be less than max health (\(self.maxHealth))"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

These are changed to strict inequalities, but not the corresponding ones in SetMinHealth/SetMaxHealth? We should be consistent in whether we want min <= target <= max vs min < target < max.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Good point, I think strict inequalities makes the most sense. 741e9a7

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

interesting, i typically expect inclusive, since the "max a value can be" in my mind definitely includes that value. Anyway, i'm okay either way as long as it's consistent

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yeah, I guess it depends on the context. In this case, a config of for exampleminHealth=targetHealth would result in us "rebalancing" a position directly into a state where it is eligible for rebalancing again. That's why strict inequality seems more appropriate to me in this case.

Copy link
Copy Markdown
Member

@zhangchiqing zhangchiqing left a comment

Choose a reason for hiding this comment

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

LGTM. Also agree to tim's comments.

Copy link
Copy Markdown
Member

@Kay-Zee Kay-Zee left a comment

Choose a reason for hiding this comment

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

LGTM.

Comment on lines +534 to +535
targetHealth > self.minHealth: "Target health (\(targetHealth)) must be greater than min health (\(self.minHealth))"
targetHealth < self.maxHealth: "Target health (\(targetHealth)) must be less than max health (\(self.maxHealth))"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

interesting, i typically expect inclusive, since the "max a value can be" in my mind definitely includes that value. Anyway, i'm okay either way as long as it's consistent

@jordanschalm jordanschalm merged commit 36bd88b into main Feb 12, 2026
1 check passed
@jordanschalm jordanschalm deleted the jord/position-refactoring branch February 12, 2026 04:35
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.

4 participants