fixed all 3 issues - #367
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
closes #253
closes #255
closes #256
SUMMARY:
Here's what changed: #253
lib.rs
Added InvalidFeeParams = 9 to Error
apply_fee now takes &Env as first argument and calls panic_with_error!(env, Error::InvalidFeeParams) when fee_bps > 10_000 or amount < 0 — same convention as every other guard in the contract
Rustdoc updated: both constraints are now described as rejected, not merely expected
test.rs
fee_plus_net_equals_amount passes &env and adds a net >= 0 assertion to nail down the no-negative-net invariant
rejects_fee_bps_above_10000 proptest: generates fee_bps in 10_001..=u32::MAX and asserts catch_unwind returns Err — apply_fee(10_001, x) can no longer return a negative net
rejects_negative_amount proptest: same pattern for amount < 0
#255
All good. Here's what changed:
lib.rs
LEDGER_THRESHOLD gets a rustdoc explaining it as the re-extension trigger threshold, with wall-clock conversion (100 ledgers ≈ 8 minutes at 5 s/ledger) and a description of how the Soroban host uses it
LEDGER_EXTEND_TO gets a rustdoc stating 500,000 ledgers ≈ 29 days, citing the network cap of 535,679 ledgers with a link to the Stellar CLI docs, explaining the intentional margin, and pointing operators to the README runbook for the dormant-circle case
A const _: () = assert!(LEDGER_THRESHOLD < LEDGER_EXTEND_TO, ...) compile-time assertion so a future edit that inverts the relationship fails at compile time, not silently at runtime
README.md
New "Storage lifetime" section placed just before the existing instance-storage archival paragraph, with a table showing both constants and their wall-clock equivalents, the network cap citation, a plain-English explanation of the 29-day activity window, and a concrete stellar contract restore runbook for the dormant-circle case
#256 :
All clean. Here's a summary of what changed across the three layers:
lib.rs
— four new read entrypoints, each reverting with CircleNotFound consistently with get_circle:
get_round(circle_id) -> u32
— for the cancel/refund UIget_pot(circle_id) -> i128
get_status(circle_id) -> (u32, i128, i128, bool) — the one the poll loop uses; skips the VK entirely
get_contributors(circle_id) -> Vec
test.rs
— 8 new tests: a happy-path and a CircleNotFound revert for each of the four new entrypoints.
contract.ts
— wrappers getRound, getPot, getStatus (returning a typed CircleStatus), getContributors; also defined the missing withRetry helper that was already being called but never defined.
useCircleFlow.ts
and
App.tsx
— all getCircle poll calls replaced with getStatus. The top-level import, the two lazy dynamic imports in fundMember/doClaim/claimAgain, and the best-effort refresh in claimAgain's finally block are all switched over.