You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Migration and Pin code id are two separate processes currently. When a PoE contract is migrated though we likely want the new version pinned. Not sure about the old version? It may still be used by other contracts.
Alternatively, we could have a check that ensures that the new code id is pinned and fail migration otherwise.
This case popped up in dump/restart scenario where the PoE contract validation step failed on restart. I am deactivating this hard constraint in VerifyPoEContracts now. It could be activated with this task again!
The text was updated successfully, but these errors were encountered:
I would say, the new version should be pinned if the old one was.
Not sure that can be done, as it'll require a matching between the new and old instances. Perhaps by contract name? Or perhaps, through an optional migration param, indicating the old code id?
That said, not sure how relevant this is, as I don't know the details of the migration process at the blockchain level.
Migration and Pin code id are two separate processes currently. When a PoE contract is migrated though we likely want the new version pinned. Not sure about the old version? It may still be used by other contracts.
Alternatively, we could have a check that ensures that the new code id is pinned and fail migration otherwise.
This case popped up in dump/restart scenario where the PoE contract validation step failed on restart. I am deactivating this hard constraint in
VerifyPoEContracts
now. It could be activated with this task again!The text was updated successfully, but these errors were encountered: