This repository has been archived by the owner on May 19, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
feat: reorgs outside of confirmations range handling #273
feat: reorgs outside of confirmations range handling #273
Changes from 26 commits
55be7e6
e1fcb73
626cec7
cb236cf
4ff6cfd
0699b59
ca21a7c
0a88d6a
466b556
df64345
127dc78
754b2bc
b6badf2
efca52b
ee097d7
9f825d2
c6b3120
7b76fd4
3133aa0
e17acb1
5adcd90
fea1cd8
3e7e4e9
eb11972
05d6918
8ff476f
13e1a7c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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 fromBaseEvemtsEmitter
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 ofappFactory()
...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
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