Conversation
# Conflicts: # res/sweat_claim.wasm
Fix legacy code
* feat: add burn rate for effective balance calculation * chore: rename burn threshold date * deps: add charts library * test: add vizualization for claim * fix: proper balances and window in migration * fix: don't lock account with zero balance * doc: add evaporating docs * doc: add docs for apis
* test: add tests for auth * test: add tests for legacy claim view methods * test: add tests for claim * test: add tests for burn status * test: add tests for account migration * test: add more migration tests * test: add tests for burn rate * test: add tests for burn amount calculation * test: add more tests * test: add util methods for test data
…efault (PROD-3679)
is_enabled has been dead code since it was added: initialized to true, carried through from_legacy, but nothing ever read it or set it to false. Adds set_account_enabled (Roles::Maintainer-gated, mirroring unlock_account/reset_service_call_flag) and gates claim() on it. Deliberately does not gate record_batch_for_hold(): disabling an account blocks withdrawal, it doesn't stop the contract from crediting it — avoids batch-partial-failure semantics for a feature whose actual scope wasn't specified beyond 'prepared for future releases'.
…it behavior
Both comments dated from the migration off nitka/sweat-model and were
now wrong or unclear:
- build-integration.sh claimed integration tests were 'temporarily
disabled' pending that migration — they aren't; it's a completed,
separate cargo workspace with 30 passing tests. Replaced with an
accurate description of what the script actually feeds (the wasm
integration-tests/prepare.rs deploys via CLAIM_WASM).
- helpers.rs attributed BLOCKS_PER_MINUTE to an unremovable dependency
('nitka used 240 blocks per minute') with no way for a reader to
verify or look it up. Replaced with the actual near-workspaces
Worker::fast_forward semantics (block-height delta, not real time)
and framed the constant as this suite's own empirical calibration.
Unlike the oracles admin set (small, bounded), accruals accumulated one entry per record_batch_for_hold timestamp bucket over the contract's entire pre-linear-burn operational history — it could hold far more entries than a single transaction's gas budget can iterate. Calling .clear() on it unconditionally inside migrate() risked an out-of-gas failure mid-migration on any deployment with substantial history. Reverts to just dropping old_state.accruals without attempting to clear it, same as accounts_legacy already does (for a different reason — LookupMap can't enumerate its own keys at all). A safe reclaim needs a separate, paginated cleanup path callable across multiple transactions, not an atomic clear inside migrate(). Removes unordered_map_clear_empties_a_populated_map, which validated a mechanism migrate() no longer uses and would have been misleading context for a future reader.
… (PROD-3671) accruals needs to stay reachable on Contract (carried through migrate() instead of dropped) for two reasons: a future paginated cleanup method needs something to operate on, and this view needs something to read. get_legacy_accruals_count exposes the current entry count so an operator can size the cleanup problem and later confirm when a paginated cleanup (not yet implemented, tracked in PROD-3671) has finished. StorageKey::Accruals is back to its unprefixed name since it's genuinely constructed in production code again. accounts_legacy stays dropped: LookupMap has no len()/iteration capability at all (confirmed against its full API — just get/set/insert/remove/contains_key/entry/flush), so there's no way to build an equivalent size view or cleanup path for it regardless of whether it's kept on Contract.
redundant_closure_for_method_calls: map(|account| account.into_latest()) -> map(AccountRecordVersioned::into_latest). map_unwrap_or: map(f).unwrap_or(false) -> is_some_and(f). Pure lint fixes, no behavior change — CI was failing since near-sdk 5.28 forced clippy to run --target wasm32-unknown-unknown (see prior near-sdk bump commit), which is the config that actually surfaces these pedantic lints against this module.
Verified all three (burn::SelfCallback::on_burn, clean::CleanApi::clean, claim::SelfCallback::on_transfer) have zero effect on the CI gate: clippy with --target wasm32-unknown-unknown (the only invocation that runs, since near-sdk 5.28 hard-errors on a plain host-target build) is clean with or without them. They only suppressed warning noise in a separate, non-#[cfg(test)] lib-build pass that cargo test/cargo build also run on host target, where near_bindgen's wasm-only export makes these look uncalled. Removing them matches this codebase's existing tolerance for that exact warning class elsewhere (remaining_gas, on_burn_internal, assert_enough_gas, days_to_seconds, sweat_to_atto all already show the same 'never used' warning with no suppression).
…is_claim_available Both methods needed the same claim_period_refreshed_at/claim_period availability check; claim() previously duplicated it inline (to avoid a second account lookup vs calling the is_claim_available trait method directly). Extracted claim_availability(account, now, claim_period), taking an already-fetched Option<&AccountRecord> instead of an AccountId, so both callers share one implementation: is_claim_available does its own lookup and delegates to it; claim() passes the account it already fetched, keeping the single-lookup optimization from PROD-3667 intact. Pure refactor, no behavior change — full unit and integration suites green before and after.
…_BATCH_SIZE Both currently 150, same value as before — but record_batch_for_hold and clean have different per-account costs, so a single shared constant made it awkward to tune one without affecting the other. Splitting them now, before either needs a different value.
near-sdk 5.27+ makes the `abi` feature unconditionally depend on near-global-contracts, whose StateInit type fails to compile under ABI generation (recursive-type error in its BorshSchema derive, unfixed upstream). 5.26.1 (matching sweat-token) predates that dependency, so ABI generation and embedding now work end-to-end. Our own view types switch to `#[near(serializers = [json])]`, which generates a crate-path-qualified, wasm32-target-gated `JsonSchema` impl automatically whenever near-sdk-macros builds with its `abi` feature — this is what unblocks ABI generation for our types without a direct schemars dependency or manual target-gating. Also pins a few transitive deps (time, darling, near-sys, serde_with) to versions compatible with the rust 1.86 toolchain rust-toolchain.toml now requires, and drops the wasm build's `--no-abi` flag now that both the sidecar ABI file and the embedded ABI section build cleanly.
Also adds res/sweat_claim_abi.json and res/sweat_claim_abi.zst, the sidecar ABI files cargo-near now generates alongside the wasm.
The one-time ACL migration (pre-ACL -> Contract with roles) has already run in production; drop the init(ignore_state) migrate() method along with the OldState struct, AccountRecordLegacy, the now-dead AccountRecordVersioned::from_legacy and AccrualIndex, and all migrate-specific unit/integration tests and the pre-ACL fixture wasm. get_legacy_accruals_count is preserved (moved into lib.rs) since it's still a live operator tool for the leftover accruals field, independent of migrate's presence. Rebuilt res/sweat_claim.wasm and the ABI.
Wires up Sweat-Foundation/actions@v1 release automation: publishes a GitHub release with the built wasm/ABI artifacts, stores the wasm as a blob on the sweat-multisig DAO via store_blob, and posts a Slack notification. remove-blob.yml is a workflow_dispatch-only wrapper for reclaiming a stored blob's deposit later.
…gration tests to match (#70) * supply 1 yocto to burn XCC; bump version * build binary - SHA-256 checksum hex : 45bc48bc1ee002425ec1a8636010426148052b17248d82b3192c22cab7fb3f52 - SHA-256 checksum bs58: 5hDejYDfcK7b3kHMvhiSvi4BSfJDU2vw48ZCxf8DWZAZ * Reanimate burn.rs integration tests, migrate fixture to new SWEAT API burn.rs was commented out and its bundled res/sweat.wasm was still the pre-ACL SWEAT token, which rejects the 1-yoctoNEAR deposit that burn() now attaches (8f00441). Update res/sweat.wasm to the current holding-account/ACL-role token API and adjust prepare.rs/helpers.rs (new() init args, drop removed add_oracle/tge_mint, defer_batch no longer takes holding_account_id) so the whole integration-tests suite passes against it. --------- Co-authored-by: Vasily Styagov <styagov.dev@gmail.com>
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
3 participants
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.
No description provided.