Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add force_import calls to the pallets #2963

Closed
svyatonik opened this issue Apr 19, 2024 · 0 comments · Fixed by paritytech/polkadot-sdk#4465
Closed

Add force_import calls to the pallets #2963

svyatonik opened this issue Apr 19, 2024 · 0 comments · Fixed by paritytech/polkadot-sdk#4465
Assignees
Labels
A-feat New feature or request P-Runtime

Comments

@svyatonik
Copy link
Contributor

Sometimes we need to unstuck the bridge and it is easier to do that with a separate call than with a set of set_storage calls. Let's add some calls to every pallet that will e.g. import some header without any checks. Obviously it should only be available to root (owner).

@svyatonik svyatonik added A-feat New feature or request P-Runtime labels Apr 19, 2024
@acatangiu acatangiu moved this to High Priority in Bridges + XCM Apr 19, 2024
@svyatonik svyatonik moved this from High Priority to In Progress in Bridges + XCM Apr 22, 2024
@svyatonik svyatonik self-assigned this Apr 23, 2024
github-merge-queue bot pushed a commit to paritytech/polkadot-sdk that referenced this issue May 17, 2024
…4465)

closes paritytech/parity-bridges-common#2963

See issue above for rationale
I've been thinking about adding similar calls to other pallets, but:
- for parachains pallet I haven't been able to think of a case when we
will need that given how long referendum takes. I.e. if storage proof
format changes and we want to unstuck the bridge, it'll take a large a
few weeks to sync a single parachain header, then another weeks for
another and etc.
- for messages pallet I've made the similar call initially, but it just
changes a storage key (`OutboundLanes` and/or `InboundLanes`), so
there's no any logic here and it may be simply done using
`system.set_storage`.

---------

Co-authored-by: command-bot <>
github-merge-queue bot pushed a commit to paritytech/polkadot-sdk that referenced this issue May 21, 2024
…4465)

closes paritytech/parity-bridges-common#2963

See issue above for rationale
I've been thinking about adding similar calls to other pallets, but:
- for parachains pallet I haven't been able to think of a case when we
will need that given how long referendum takes. I.e. if storage proof
format changes and we want to unstuck the bridge, it'll take a large a
few weeks to sync a single parachain header, then another weeks for
another and etc.
- for messages pallet I've made the similar call initially, but it just
changes a storage key (`OutboundLanes` and/or `InboundLanes`), so
there's no any logic here and it may be simply done using
`system.set_storage`.

---------

Co-authored-by: command-bot <>
github-merge-queue bot pushed a commit to paritytech/polkadot-sdk that referenced this issue May 21, 2024
…4465)

closes paritytech/parity-bridges-common#2963

See issue above for rationale
I've been thinking about adding similar calls to other pallets, but:
- for parachains pallet I haven't been able to think of a case when we
will need that given how long referendum takes. I.e. if storage proof
format changes and we want to unstuck the bridge, it'll take a large a
few weeks to sync a single parachain header, then another weeks for
another and etc.
- for messages pallet I've made the similar call initially, but it just
changes a storage key (`OutboundLanes` and/or `InboundLanes`), so
there's no any logic here and it may be simply done using
`system.set_storage`.

---------

Co-authored-by: command-bot <>
@github-project-automation github-project-automation bot moved this from In Progress to Done in Bridges + XCM May 21, 2024
hitchhooker pushed a commit to ibp-network/polkadot-sdk that referenced this issue Jun 5, 2024
…aritytech#4465)

closes paritytech/parity-bridges-common#2963

See issue above for rationale
I've been thinking about adding similar calls to other pallets, but:
- for parachains pallet I haven't been able to think of a case when we
will need that given how long referendum takes. I.e. if storage proof
format changes and we want to unstuck the bridge, it'll take a large a
few weeks to sync a single parachain header, then another weeks for
another and etc.
- for messages pallet I've made the similar call initially, but it just
changes a storage key (`OutboundLanes` and/or `InboundLanes`), so
there's no any logic here and it may be simply done using
`system.set_storage`.

---------

Co-authored-by: command-bot <>
TarekkMA pushed a commit to moonbeam-foundation/polkadot-sdk that referenced this issue Aug 2, 2024
…aritytech#4465)

closes paritytech/parity-bridges-common#2963

See issue above for rationale
I've been thinking about adding similar calls to other pallets, but:
- for parachains pallet I haven't been able to think of a case when we
will need that given how long referendum takes. I.e. if storage proof
format changes and we want to unstuck the bridge, it'll take a large a
few weeks to sync a single parachain header, then another weeks for
another and etc.
- for messages pallet I've made the similar call initially, but it just
changes a storage key (`OutboundLanes` and/or `InboundLanes`), so
there's no any logic here and it may be simply done using
`system.set_storage`.

---------

Co-authored-by: command-bot <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-feat New feature or request P-Runtime
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant