-
Notifications
You must be signed in to change notification settings - Fork 18
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
GRPH-90 Fix for history ID mismatch issue #117
Conversation
@ronakpatel3110 - Please provide the steps to verify this PR. |
30d50fb
to
3510704
Compare
@ronakpatel3110 - Can you think of specific steps for the QA team to verify this PR ? |
Testcases: The testing steps involves undoing a block which is difficult/impossible for QA to do without touching the code. QA can run below test cases to confirm this change is working:
|
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.
LGTM
The testing steps involves undoing a block which is difficult/impossible for QA to do without touching the code. QA can run below test cases and observe the same output to confirm this change is working:
|
feature build is failing and we need to investigate this |
A node with track-account configured has bigger history_object_id's (1.11.x) than nodes with default configuration values.
The problem was caused by using of use_next_id().
When creating new objects, old_index_next_ids will be updated in on_create(), when undoing, the value will be reverted to saved old id.
But in history plugin we didn't save old ids in old_index_next_ids, thus no reversion will be done when undoing.
Bitshares PR: bitshares/bitshares-core#875