-
Notifications
You must be signed in to change notification settings - Fork 86
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
[CAD-3723] Add progress to initial chain selection #3518
[CAD-3723] Add progress to initial chain selection #3518
Conversation
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.
Looks super to me. 👌
ouroboros-consensus/src/Ouroboros/Consensus/Storage/LedgerDB/InMemory.hs
Outdated
Show resolved
Hide resolved
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 left some comments. We can have a call to discuss them.
ouroboros-consensus/src/Ouroboros/Consensus/Storage/LedgerDB/InMemory.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/src/Ouroboros/Consensus/Storage/LedgerDB/InMemory.hs
Outdated
Show resolved
Hide resolved
|
||
-- | Switch to a fork | ||
ledgerDbSwitch :: (ApplyBlock l blk, Monad m, c) | ||
=> LedgerDbCfg l | ||
-> Word64 -- ^ How many blocks to roll back | ||
-> (UpdateLedgerDbTraceEvent blk -> m ()) |
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 principle, this could be any action. I wonder if we want to be more specific and declare that this should actually be a tracer.
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.
Good question, but at least debatable. Even though I follow your line of thought and you are right, in principle this could be any hook but:
a) this could be a slipper slope to messy code in a future, because it is so easy to just "add one more thing" to a hook.
b) I've followed existing convention in our code were we pass trace
functions as arguments
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.
data ChainSelEnv m blk = ChainSelEnv
{ lgrDB :: LgrDB m blk
, trace :: TraceValidationEvent blk -> m ()
ChainSelEnv
is using trace
and that pollutes our design. I think I will change that to provide a tracer
instead but in a follow up PR.
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 should be Tracer
. Tracer is isomorphic to that type, and transparent, so there's no restriction gained by using either type. But Tracer
is the tell-tale type throughout our codebase for this kind of concern.
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.
@nfrisby are you ok with doing this in separate PR so this one does not get polluted with too many concerns?
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 for the the new field it should just be Tracer
, regardless of new code, but yeah no need to change existing code in this PR.
Edit: eg you could use nullTracer
instead of const $ pure ()
etc. Tracer
is the right API for this sort of thing.
f1e6637
to
f50db87
Compare
Those events tracks changes done to LedgerDB each time block is added/applied to it. User gets notiftied twice: once the block is about to be applied and the moment after it got applied
Also remove PushedBlockToTheLedgerDb
d76ef34
to
d2f234d
Compare
While pushing blocks to ledger we can trace progress. This means that the cardano-node can present that progress to the user of the node, possibly in the for of progress bar or printing out percentage
ouroboros-consensus/src/Ouroboros/Consensus/Storage/LedgerDB/InMemory.hs
Show resolved
Hide resolved
ouroboros-consensus/src/Ouroboros/Consensus/Storage/LedgerDB/Types.hs
Outdated
Show resolved
Hide resolved
res <- ledgerDbPush cfg ap db | ||
return res | ||
pushAndTrace ap db = do | ||
traceStep $ StartedPushingBlockToTheLedgerDb (Pushing $ toRealPoint ap) |
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.
What about something more direct (with the use of auxiliary mk
functions)?
trace $ tartedPushingBlockToTheLedgerDb $ (mkPushing ap ) (mkPushGoal aps)
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 like it
@@ -208,6 +208,9 @@ initLgrDB k chain = do | |||
|
|||
genesisLedgerDB = LgrDB.ledgerDbWithAnchor testInitExtLedger | |||
|
|||
noopTrace :: blk -> m () |
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.
We have other uses of const $ pure ()
. Don't we want to replace these with noopTrace
? Or just use const $ pure ()
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.. good question, i think it's better if we replace with noop
helper function, otherwise someone who will read the code will have to check each time to understand "wtf is const pure unit"
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 left some comments. LGTM.
b67a2e4
to
4a5633a
Compare
StartedPushingBlockToTheLedgerDb | ||
!(Pushing blk) | ||
-- ^ Point which block we are about to push | ||
(PushGoal blk) |
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.
Is there a !
missing here?
bors merge |
Build succeeded: |
@@ -323,6 +325,7 @@ initStartingWith tracer cfg streamAPI initDb = do | |||
(ledgerState (ledgerDbCurrent db)) | |||
(ledgerState (ledgerDbCurrent db')) | |||
|
|||
|
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.
Style: undue newline
@@ -533,4 +535,5 @@ data TraceReplayEvent blk replayTo | |||
-- The @blockInfo@ parameter corresponds replayed block and the @replayTo@ | |||
-- parameter corresponds to the block at the tip of the ImmutableDB, i.e., | |||
-- the last block to replay. | |||
| UpdateLedgerDbTraceEvent (UpdateLedgerDbTraceEvent blk) |
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.
Please add a Haddock comment on this one, describing the general meaning of the UpdateLedgerDbTraceEvent
type/category.
where | ||
pushAndTrace ap db = do | ||
let pushing = Pushing . toRealPoint $ ap | ||
goal = PushGoal . toRealPoint . last $ aps |
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'd prefer to not call partial functions correctly. So write a case expression with a nice error
message instead of calling last
.
Edit: Or, depending on the call site, I wouldn't be too surprised if it were possible to change the type from []
to NonEmpty
Bah --- I just realized this was already Merged :) |
No description provided.