Tags: dfinity/ic
Tags
test(registry): Set up sharded routing table in registry tests (#5810) Routing table format is being changed from a single value to sharded values. This PR sets up the sharded routing table in addition to the single routing table. --------- Co-authored-by: Max Summe <maximilian.summe@dfinity.org>
docs(nns): Add a comment regarding routing table shards (#5806) Better document the invariants for routing table shards so that it's clearer that tests set up with a single shard key `make_canister_ranges_key(CanisterId::from_u64(0))` is correct. It should also help with future functionalities where shards are partially read (e.g. binary search a specific shard)
chore: update ic-rosetta-api to version 2.1.6 (#5772) - Bump version to 2.1.6 in Cargo.lock, Cargo.toml, and BUILD.bazel - Add new features for transaction search capabilities and database indexing optimizations - Extend search_transactions method to support filtering by transaction_hash and operation_type - Introduce optional CLI flag --optimize-search-indexes - Enhance test framework for transfer_from transactions and mark ICP Rosetta system tests as flaky for stability
chore: update ic-rosetta-api to version 2.1.6 (#5772) - Bump version to 2.1.6 in Cargo.lock, Cargo.toml, and BUILD.bazel - Add new features for transaction search capabilities and database indexing optimizations - Extend search_transactions method to support filtering by transaction_hash and operation_type - Introduce optional CLI flag --optimize-search-indexes - Enhance test framework for transfer_from transactions and mark ICP Rosetta system tests as flaky for stability
test: Improve fake mounter with persistent mounts (#5709) Make `ExtractingFilesystemMounter` act persistently, so mounting the same partition multiple times should return the same directory. This is closer to reality, since changes in a mounted filesystem should be visible when the same partition is mounted again.
refactor(nns): Refactor distribute_rewards to separate immutable and … …mutable operations (#5494) # Why The `distribute_rewards` method is quite large and it has a lot of complicated calculations. When we look at the whole method, it's hard to distinguish the calculations from the mutations (schedule rewards distribution, process proposals etc.) For situations like this, it's often better to separate the immutable operations from the mutable ones. # What * Refactor the calculation logic in `distribute_rewards` to `calculate_voting_rewards`
PreviousNext