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

pool: chore: make reserve caching system more obvious to use #180

Merged
merged 5 commits into from
Jan 4, 2024

Conversation

mootz12
Copy link
Contributor

@mootz12 mootz12 commented Jan 3, 2024

There was some concern that it was not obvious and potentially error prone that developers could misuse the "reserves_to_store" component of the Pool reserve cache.

The fix was to make it more obvious the intention of a developer as they used it. I opted for this over an explicit "store unless defused" mechanism because we often read reserves we don't want to store as a final step (IE - checking the health factor in submit).

The fix requires the developer to state if they want to store the reserve when they load it, and the pool will validate that no reserve is missing from the cache that it expects to write back. This prevents the case where a developer forgets to store the updated reserve before calling pool.store_cached_reserves.

@mootz12 mootz12 linked an issue Jan 3, 2024 that may be closed by this pull request
Ryang-21
Ryang-21 previously approved these changes Jan 4, 2024
@Ryang-21
Copy link
Contributor

Ryang-21 commented Jan 4, 2024

lgtm

feat: use standard initialization logic
pool: fix: update reactivity constant bounds
@mootz12 mootz12 merged commit cd8e248 into main Jan 4, 2024
3 checks passed
@mootz12 mootz12 deleted the reserve-cache branch January 4, 2024 19:40
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.

BLRC-002 - Potential pitfalls in reserve loading and caching mechanism
2 participants