1. Apr 02, 2024
    • Dastan's avatar
      migrations: prevent accidentally using unversioned migrations instead of... · e5427969
      Dastan authored
      migrations: prevent accidentally using unversioned migrations instead of `VersionedMigration` (#3835)
      
      closes #1324 
      
      #### Problem
      Currently, it is possible to accidentally use inner unversioned
      migration instead of `VersionedMigration` since both implement
      `OnRuntimeUpgrade`.
      
      #### Solution
      
      With this change, we make it clear that value of `Inner` is not intended
      to be used directly. It is achieved by bounding `Inner` to new trait
      `UncheckedOnRuntimeUpgrade`, which has the same interface (except
      `unchecked_` prefix) as `OnRuntimeUpgrade`.
      
      #### `try-runtime` functions
      
      Since developers can implement `try-runtime` for `Inner` value in
      `VersionedMigration` and have custom logic for it, I added the same
      `try-runtime` functions to `UncheckedOnRuntimeUpgrade`. I looked for a
      ways to not duplicate functions, but couldn't find anything that doesn't
      significantly change the codebase. So I would appreciate If you have any
      suggestions to improve this
      
      cc @liamaharon
      
       @xlc 
      
      polkadot address: 16FqwPZ8GRC5U5D4Fu7W33nA55ZXzXGWHwmbnE1eT6pxuqcT
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      e5427969
    • Serban Iorga's avatar
      Align dependencies with `parity-bridges-common` (#3937) · 8e95a3e1
      Serban Iorga authored
      Working towards migrating the `parity-bridges-common` repo inside
      `polkadot-sdk`. This PR upgrades some dependencies in order to align
      them with the versions used in `parity-bridges-common`
      
      Related to
      https://github.com/paritytech/parity-bridges-common/issues/2538
      8e95a3e1
    • Alexandru Vasile's avatar
      chainHead: Allow methods to be called from within a single connection context... · 7430f413
      Alexandru Vasile authored
      chainHead: Allow methods to be called from within a single connection context and limit connections (#3481)
      
      This PR ensures that the chainHead RPC class can be called only from
      within the same connection context.
      
      The chainHead methods are now registered as raw methods. 
      - https://github.com/paritytech/jsonrpsee/pull/1297
      The concept of raw methods is introduced in jsonrpsee, which is an async
      method that exposes the connection ID:
      The raw method doesn't have the concept of a blocking method. Previously
      blocking methods are now spawning a blocking task to handle their
      blocking (ie DB) access. We spawn the same number of tasks as before,
      however we do that explicitly.
      
      Another approach would be implementing a RPC middleware that captures
      and decodes the method parameters:
      - https://github.com/paritytech/polkadot-sdk/pull/3343
      However, that approach is prone to errors since the methods are
      hardcoded by name. Performace is affected by the double deserialization
      that needs to happen to extract the subscription ID we'd like to limit.
      Once from the middleware, and once from the methods itself.
      
      This PR paves the way to implement the chainHead connection limiter:
      - https://github.com/paritytech/polkadot-sdk/issues/1505
      Registering tokens (subscription ID / operation ID) on the
      `RpcConnections` could be extended to return an error when the maximum
      number of operations is reached.
      
      While at it, have added an integration-test to ensure that chainHead
      methods can be called from within the same connection context.
      
      Before this is merged, a new JsonRPC release should be made to expose
      the `raw-methods`:
      - [x] Use jsonrpsee from crates io (blocked by:
      https://github.com/paritytech/jsonrpsee/pull/1297)
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/3207
      
      
      
      
      cc @paritytech/subxt-team
      
      ---------
      
      Signed-off-by: default avatarAlexandru Vasile <[email protected]>
      Co-authored-by: default avatarNiklas Adolfsson <[email protected]>
      7430f413
    • Adrian Catangiu's avatar
      beefy: error logs for validators with dummy keys (#3939) · 5eff3f94
      Adrian Catangiu authored
      This outputs:
      ```
      2024-04-02 14:36:02.135 ERROR tokio-runtime-worker beefy: 🥩 for session starting at block 21990151
      no BEEFY authority key found in store, you must generate valid session keys
      (https://wiki.polkadot.network/docs/maintain-guides-how-to-validate-polkadot#generating-the-session-keys
      
      )
      ```
      error log entry, once every session, for nodes running with
      `Role::Authority` that have no public BEEFY key in their keystore
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      5eff3f94
    • Serban Iorga's avatar
      Update bridges subtree (#3938) · d5617cf3
      Serban Iorga authored
      Pulling the latest changes from `parity-bridges-common`
      d5617cf3
    • Javier Viola's avatar
      chore(zombienet): bump version (#3933) · db1af43c
      Javier Viola authored
      This version includes:
      
      - Internal metrics of zombienet (used to benchmark with v2).
      db1af43c
    • Bastian Köcher's avatar
      Fix parachain upgrade scheduling when done by the owner/root (#3341) · 12eb285d
      Bastian Köcher authored
      When using `schedule_code_upgrade` to change the code of a parachain in
      the relay chain runtime, we had already fixed to not set the `GoAhead`
      signal. This was done to not brick any parachain after the upgrade,
      because they were seeing the signal without having any upgrade prepared.
      The remaining problem is that the parachain code is only upgraded after
      a parachain header was enacted, aka the parachain made some progress.
      However, this is quite complicated if the parachain is bricked (which is
      the most common scenario why to manually schedule a code upgrade). Thus,
      this pull request replaces `SetGoAhead` with `UpgradeStrategy` to signal
      to the logic kind of strategy want to use. The strategies are either
      `SetGoAheadSignal` or `ApplyAtExpectedBlock`. `SetGoAheadSignal` sets
      the go ahead signal as before and awaits a parachain block.
      `ApplyAtExpectedBlock` schedules the upgrade and applies it directly at
      the `expected_block` without waiting for the parachain to make any kind
      of progress.
      12eb285d
    • Adrian Catangiu's avatar
      pallet-xcm: fix weights for all XTs and deprecate unlimited weight ones (#3927) · d0ebb850
      Adrian Catangiu authored
      
      
      Fix "double-weights" for extrinsics, use only the ones benchmarked in
      the runtime.
      
      Deprecate extrinsics that don't specify WeightLimit, remove their usage
      across the repo.
      
      ---------
      
      Signed-off-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: command-bot <>
      d0ebb850
    • Sam Johnson's avatar
      Update derive syn parse 0.2.0 (+ docify) (#3920) · 9a62de27
      Sam Johnson authored
      
      
      derive-syn-parse v0.2.0 came out recently which (finally) adds support
      for syn 2x.
      
      Upgrading to this will remove many of the places where syn 1x was still
      compiling alongside syn 2x in the polkadot-sdk workspace.
      
      This also upgrades `docify` to 0.2.8 which is the version that upgrades
      derive-syn-pasre to 0.2.0.
      
      Additionally, this consolidates the `docify` versions in the repo to all
      use the latest, and in one case upgrades to the 0.2x syntax where 0.1.x
      was still being used.
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      9a62de27
  2. Apr 01, 2024
  3. Mar 31, 2024
  4. Mar 29, 2024
  5. Mar 28, 2024
  6. Mar 27, 2024