-
Notifications
You must be signed in to change notification settings - Fork 3
feat: reorgs outside of confirmations range handling #273
Conversation
This pull request introduces 2 alerts when merging 55be7e6 into a5b3a18 - view on LGTM.com new alerts:
|
refactor db-backup job
This pull request introduces 1 alert when merging e1fcb73 into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 626cec7 into a5b3a18 - view on LGTM.com new alerts:
|
add basic unit test for backup job constructor
This pull request introduces 1 alert when merging 0699b59 into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 1dd69b7 into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 3 alerts when merging ca21a7c into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 0a88d6a into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 466b556 into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging df64345 into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 127dc78 into a5b3a18 - view on LGTM.com new alerts:
|
add reorg service to blockchain init and channels subscribe for reorgs for each of services and emit using reorg service
This pull request introduces 2 alerts when merging 754b2bc into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging b6badf2 into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 2cfd958 into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging efca52b into a5b3a18 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 7b76fd4 into 25db5ac - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging e17acb1 into 25db5ac - view on LGTM.com new alerts:
|
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.
Hmm there are few questions and some things to improve. But it is on good path!
|
||
const app = await appFactory() | ||
const port = config.get('port') | ||
const server = app.listen(port) |
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.
To be honest, I don't really like moving the server start&listening logic to the appFactory()
. I don't actually think that it has to be there right? What was your motivation here?
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.
In this shape it is not a "factory" anymore...
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.
Just want to make the same as we had it in pinner, as we use the same algorithm for reorgs
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.
Hmmmmmm. I see you renamed it to startApp
. I am still against this refactor. While I understand your motivation, the Pinner and Cache are different things, using different setups (Cache uses Feathers and it is a Web Server, Pinner is a specific custom-built daemon service). Yes, we use the same mechanism for handling reorgs, but the context is a bit different. You can still use this "algorithm" even with the original approach of appFactory()
...
I think that bootstrapping the Feather's app and actually starting the listening on a port should be kept separate.
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.
Reverted back
@@ -29,7 +28,7 @@ export function isServiceInitialized (serviceName: string): boolean { | |||
return blockTracker.getLastFetchedBlock()[0] !== undefined | |||
} | |||
|
|||
export function getEventsEmitterForService (serviceName: string, eth: Eth, contractAbi: AbiItem[]): EventEmitter { | |||
export function getEventsEmitterForService (serviceName: string, eth: Eth, contractAbi: AbiItem[]): BaseEventsEmitter { |
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.
Why do you need the BaseEvemtsEmitter
?
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.
I need the stop
method from BaseEvemtsEmitter
@@ -28,7 +29,8 @@ export enum ServiceAddresses { | |||
STORAGE_AGREEMENTS = '/storage/v0/agreements', | |||
XR = '/rates/v0/', | |||
CONFIRMATIONS = '/confirmations', | |||
NEW_BLOCK_EMITTER = '/new-block' | |||
NEW_BLOCK_EMITTER = '/new-block', | |||
REORG_EMITTER = '/reorg' |
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.
Hmm I think we should incorporate in the naming of variables, paths etc the fact the this is not normal reorg but reorg outside of confirmation range. Because these two are different and it can lead to confusion later on.
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.
I think it's fine as we can have different events based on this path. Separation happens there
src/utils.ts
Outdated
type BackUpEntry = { name: string, block: { hash: string, number: BigNumber } } | ||
|
||
function parseBackUps (backUpName: string): BackUpEntry { | ||
const [block] = backUpName.split('.')[0].split('-') |
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.
Hmm what length of the names you usually get? Just to make sure we won't run in problems with FS...
My original idea was actually store these data as part of the Store, but I guess this will work as well 😊
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.
Not too big, like: add-name-to-user
src/cli/start.ts
Outdated
backUpJob.stop() | ||
|
||
// Restore DB from backup | ||
await backUpJob.restoreDb(() => undefined) |
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.
Why do you "ignore" the errorCallback
here? And actually why there is even such a thing? Isn't rejected Promise enough?
c6fb36d
to
9836164
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.
Hmm still some things to tackle.
Btw. did you test how the UI handles when Cache disconnects? We should know its behavior as maybe there should be some added logic to the UI for handling when Cache is not online and also to listen on the Reorg channel...
Also, please don' do force-push once the review process starts. It makes it hard for me to track the increment changes you are making especially in big PRs like this...
|
||
const app = await appFactory() | ||
const port = config.get('port') | ||
const server = app.listen(port) |
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.
Hmmmmmm. I see you renamed it to startApp
. I am still against this refactor. While I understand your motivation, the Pinner and Cache are different things, using different setups (Cache uses Feathers and it is a Web Server, Pinner is a specific custom-built daemon service). Yes, we use the same mechanism for handling reorgs, but the context is a bit different. You can still use this "algorithm" even with the original approach of appFactory()
...
I think that bootstrapping the Feather's app and actually starting the listening on a port should be kept separate.
src/cli/start.ts
Outdated
backUpJob.stop() | ||
|
||
// Restore DB from backup | ||
await backUpJob.restoreDb() |
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.
Hmmm so if the restore procedure fails for some reason then Cache craches, right? 🤔
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.
Yes, it's true. For that case, we should notify DevOps that the restore process fails
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
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! Thanks!
No description provided.