Skip to content

VDB-1420: add storage diff statuses#128

Merged
rmulhol merged 9 commits intostagingfrom
vdb-1420-add-storage-diff-statuses
Aug 25, 2020
Merged

VDB-1420: add storage diff statuses#128
rmulhol merged 9 commits intostagingfrom
vdb-1420-add-storage-diff-statuses

Conversation

@elizabethengelman
Copy link
Copy Markdown

@elizabethengelman elizabethengelman commented Aug 19, 2020

@@ -198,7 +194,24 @@ func (watcher StorageWatcher) handleDiffWithInvalidHeaderHash(diff types.Persist
return fmt.Errorf(msg, diff.ID, maxBlockErr)
}
if diff.BlockHeight < int(maxBlock)-ReorgWindow {
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wanted another set of eyes on this. When handling diffs with invalid header hash, it looks like if the diff's blockHeight is still within the ReorgWindow, then we're not changing the status on that diff. I think this makes sense, because it's possible that the given diff is actually canonical, but the reorg is currently in progress. So, I think by not setting the status, this diff will be pulled in again for processing in the future. Is that how others are understanding this as well?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep 👍

@elizabethengelman elizabethengelman changed the title Vdb 1420 add storage diff statuses VDB-1420: add storage diff statuses Aug 19, 2020
logrus.Infof("error transforming diff: %s", transformErr.Error())
}
if handleErr := watcher.handleTransformError(transformErr, diff); handleErr != nil {
return handleErr
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this get the fmt.Errorf treatment?

Copy link
Copy Markdown

@paytonrules paytonrules left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢

var status string
getStatusErr := db.Get(&status, `SELECT status FROM public.storage_diff WHERE id = $1`, fakePersistedDiff.ID)
Expect(getStatusErr).NotTo(HaveOccurred())
Expect(status).To(Equal("unwatched"))
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nbd but I wonder if we should wrap these strings (e.g. "new", "unrecognized", "noncanonical", "unwatched", "transformed") in vars so that we can change them in one place if we change the enum in the DB

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i like this idea!

'transformed',
'unrecognized',
'noncanonical',
'unwatched'
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no real action item here but definitely want to think about how we can potentially accommodate multiple plugins/execute processes - where a diff that's "unwatched" for one plugin might still be relevant to another. Given that we're getting better about configuring which contracts we're tracking, I almost wonder if we can eventually discard this status entirely 🤔

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 Yeah, this is a good call. Do you think it's worth removing this status now? We could leave those diffs with a status as 'new' for now? I think those diffs won't get constantly pulled if we've set DiffBlocksFromHeadOfChain.

@rmulhol rmulhol merged commit 22df7c3 into staging Aug 25, 2020
@rmulhol rmulhol deleted the vdb-1420-add-storage-diff-statuses branch August 25, 2020 19:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants