Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Retire OldV1SessionInfo #6722

Closed
s0me0ne-unkn0wn opened this issue Feb 15, 2023 · 3 comments · Fixed by #6744
Closed

Retire OldV1SessionInfo #6722

s0me0ne-unkn0wn opened this issue Feb 15, 2023 · 3 comments · Fixed by #6744
Labels
I8-refactor Code needs refactoring.

Comments

@s0me0ne-unkn0wn
Copy link
Contributor

SessionInfos are kept on-chain for the dispute period, which is six sessions on production networks. An older version of the structure known as OldV1SessionInfo (see #4545) had its transition period since inclusion in the 0.9.16 release in February 2022. I believe it can be safely retired now, getting rid of some messy versioning code introduced during the transition.

@s0me0ne-unkn0wn
Copy link
Contributor Author

s0me0ne-unkn0wn commented Feb 15, 2023

@tdimitrov, it's your field of expertise. If I remove the structure from primitives and remove all the code making use of it, is it safe and sound to remove the #[changed_in(2)] session_info() declaration and forget about it?

@tdimitrov
Copy link
Contributor

I'm afraid I've got no idea :(

@bkchr is it safe to remove method declarations from the runtime API if we are on a newer stable version? Are they needed for processing old blocks?

This is the method @s0me0ne-unkn0wn refers to.

@rphmeier
Copy link
Contributor

Are they needed for processing old blocks?

No. Only the old runtime is needed to process old blocks. Runtime APIs are used to coordinate work around the head of the chain, not around old blocks.

They are safe to remove when any code invoking the old runtime API has been removed from all node binaries.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
I8-refactor Code needs refactoring.
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants