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 Header fields while maintaining backwards compatibility #7820

Open
Tracked by #7363
joshieDo opened this issue Apr 23, 2024 · 1 comment
Open
Tracked by #7363

Add Header fields while maintaining backwards compatibility #7820

joshieDo opened this issue Apr 23, 2024 · 1 comment
Labels
A-db Related to the database E-prague Related to the prague network upgrade M-prevent-stale Prevents old inactive issues/PRs from being closed due to inactivity S-needs-investigation This issue requires detective work to figure out what's going wrong

Comments

@joshieDo
Copy link
Collaborator

joshieDo commented Apr 23, 2024

Describe the feature

With Prague coming up, we should take this into account.

Generally with Compact, the reader first reads a fixed size bitflag struct (eg. HeaderFlags) and uses that to read the number of bytes necessary for each field.

As long as there are bits available on this bitflag struct, we can keep adding new fields to Header under the form of Option<FIELD> while maintaing backwards compatability. Each Option<> uses one bit in the bitflag struct. However, we have reached the limit, there's only one bit left.

#[doc =
        "Fieldset that facilitates compacting the parent type. Used bytes: 4 | Unused bits: 1"]
        #[allow(clippy :: identity_op)]
        pub struct HeaderFlags {

The next Option<N> has to be something like Option<HeaderExt>. N can be whatever we want it to be.
Previous instances of Header will read that bit flag as 0 and ignore that field, and the new Header changes will read that bit as 1 and decode it

Additional context

No response

@joshieDo joshieDo added S-needs-investigation This issue requires detective work to figure out what's going wrong E-prague Related to the prague network upgrade A-db Related to the database labels Apr 23, 2024
Copy link
Contributor

This issue is stale because it has been open for 21 days with no activity.

@github-actions github-actions bot added the S-stale This issue/PR is stale and will close with no further activity label May 15, 2024
@mattsse mattsse added M-prevent-stale Prevents old inactive issues/PRs from being closed due to inactivity and removed S-stale This issue/PR is stale and will close with no further activity labels May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-db Related to the database E-prague Related to the prague network upgrade M-prevent-stale Prevents old inactive issues/PRs from being closed due to inactivity S-needs-investigation This issue requires detective work to figure out what's going wrong
Projects
Status: Todo
Development

No branches or pull requests

2 participants