-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
wtclient+migration: start storing chan max height in channel details bucket #8222
wtclient+migration: start storing chan max height in channel details bucket #8222
Conversation
8763f0b
to
2a9943d
Compare
96f20e3
to
2683940
Compare
2683940
to
0ebc5eb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent work 🍫
0ebc5eb
to
5047341
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice and clean PR👍 Have minor questions, otherwise LGTM🙏
In this commit, a new key, cChanMaxCommitmentHeight, is added to the channel details bucket. This key will hold the highest commitment number that the tower has been handed for this channel. In this commit, we start writing to it in the two places where a backup is first persisted in the tower client db: 1) CommitUpdate and 2) in the Queue's `addItem` method. The logic for both 1 & 2 is tested in the next commit which adds a DB helper that allows us to read the new field. A follow up commit will do a migration to back-fill the new field.
This commit also adds tests for the DB changes made in the previous commit since we can now read the new field with the FetchChanInfos method. The commit following this one does the backfill migration.
5047341
to
3642cb6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🏖
The problem
See the problem described in detail here: #8221
The solution:
This PR implements the first solution step defined in the issue. I'll repeat it here:
This PR removes the need to iterate through all the sessions & range indices on each start-up.
It does this by: