1. Apr 26, 2022
  2. Apr 25, 2022
    • tgmichel's avatar
      Add `chain-info` Subcommand (#11250) · 5eb2e329
      tgmichel authored
      
      
      * Add `blockchain-info` Subcommand
      
      * Update comment
      
      * Cleanup
      
      * Cleanup
      
      * Use `sync_run`
      
      * Use `sc_client_db` utility fns instead service backend
      
      * Use service `Backend` builder
      
      * Impl `From<sp_blockchain::Info>`
      
      * Rename to `chain-info`
      
      * fmt
      
      * Copyright year
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      
      * Expose `DatabaseParams`
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      5eb2e329
    • Bastian Köcher's avatar
      pallet-asset: Fix transfer of a large amount of an asset (#11241) · 2541efdb
      Bastian Köcher authored
      
      
      * pallet-asset: Fix transfer of a large amount of an asset
      
      Before this pr transferring a large amount of an asset would check that transferring the asset would
      not overflow the supply of the asset. However, it doesn't make sense to check for asset supply
      overflow when we just transfer from one account to another account and don't increase the supply in
      any way. It also required to extend the `can_deposit` method of `fungible` and `fungibles` with a
      `mint` parameter. If this parameter is set to `true`, it means we want to mint the amount of an
      asset before transferring it into an account. For `can_withdraw` we don't need to add an extra
      parameter, because withdrawing should never be able to underflow the supply. If that would happen,
      it would mean that somewhere the supply wasn't increased while increasing the balance of an account.
      
      * Update frame/assets/src/functions.rs
      
      * Update frame/assets/src/functions.rs
      
      * Update frame/assets/src/functions.rs
      
      Co-authored-by: default avatarShawn Tabrizi <[email protected]>
      
      * FMT
      
      Co-authored-by: default avatarShawn Tabrizi <[email protected]>
      2541efdb
    • Bastian Köcher's avatar
      cumulus-companion: Fix CI when there is no Polkadot companion (#11280) · 914db49d
      Bastian Köcher authored
      This tries to fix the CI if there is no polkadot companion. Currently we don't update Polkadot
      master in Cumulus, which means we may use some old commit that isn't compiling with the latest
      Substrate master anymore. This can happen if there was a pr that had a companion in Polkadot, but no
      companion was required for Cumulus. Then Cumulus will still point to some old Polkadot commit that
      isn't compiling anymore with the latest Substrate commit. So, we need to tell the script to use the
      latest master of Polkadot. If there is a companion for Polkadot, it would simply override the extra
      dependency patch later on.
      914db49d
    • Nazar Mokrynskyi's avatar
  3. Apr 22, 2022
  4. Apr 21, 2022
  5. Apr 20, 2022
  6. Apr 19, 2022
  7. Apr 18, 2022
  8. Apr 16, 2022
  9. Apr 15, 2022
  10. Apr 14, 2022
  11. Apr 13, 2022
  12. Apr 12, 2022
    • Qinxuan Chen's avatar
      Bump soketto to v0.7.1 (#11203) · 3fec1082
      Qinxuan Chen authored
      
      
      Signed-off-by: default avatarkoushiro <[email protected]>
      3fec1082
    • Denis_P's avatar
      CI: rename ambiguous jobs (#11207) · ba8beeed
      Denis_P authored
      ba8beeed
    • Bastian Köcher's avatar
      Finality notification: Optimize calculation of stale heads (#11200) · cc4b5c48
      Bastian Köcher authored
      
      
      * Finality notification: Optimize calculation of stale heads
      
      While looking into some problem on Versi where a collator seemed to be stuck. I found out that it
      was not stuck but there was a huge gap between last finalized and best block. This lead to a lot
      leaves and it was basically trapped inside some loop of reading block headers from the db to find
      the stale heads. While looking into this I found out that `leaves` already supports the feature to
      give us the stale heads relative easily. However, the semantics change a little bit. Instead of
      returning all stale heads of blocks that are not reachable anymore after finalizing a block, we
      currently only return heads with a number lower than the finalized block. This should be no problem,
      because these other leaves that are stale will be returned later when a block gets finalized which
      number is bigger than the block number of these leaves.
      
      While doing that, I also changed `tree_route` of the `FinalityNotification` to include the
      `old_finalized`. Based on the comment I assumed that this was already part of it. However, if
      wanted, I can revert this change.
      
      * FMT
      
      * Update client/service/src/client/client.rs
      
      Co-authored-by: default avatarAndré Silva <[email protected]>
      
      * Do not include the last finalized block
      
      * Rename function
      
      * FMT
      
      * Fix tests
      
      * Update figure
      
      Co-authored-by: default avatarAndré Silva <[email protected]>
      cc4b5c48