-
Notifications
You must be signed in to change notification settings - Fork 720
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
block forging tracing details at default log level #528
Comments
So it looks like the |
for analysing benchmarking runs we read the blocks <-> tx relation from |
example:
|
537: Update `TraceForgeEvent` logging details r=Jimbo4350 a=Jimbo4350 - Update tracer `TraceAdoptedBlock` to log the block hash and a list of txids in that block. Example output: `[cardano.node.Forge:Info:61] [2020-02-04 18:08:26.00 UTC] {"kind":"TraceAdoptedBlock","slot":6,"tx ids":"[txid: txid:6875a2f9]","block hash":"a6d8325832257989"}` - Update the following tracers to `Error` severity: `TraceNoLedgerState` `TraceNoLedgerView` `TraceBlockFromFuture` `TraceDidntAdoptBlock` `TraceForgedInvalidBlock` Relevant issue: #528 Co-authored-by: Jordan Millar <[email protected]>
We need to ensure that at the default tracing levels we get the crucial information needed to trace a tx through the mempool of multiple nodes and into a block, to see where it got to.
So at default logging level:
TraceAdoptedBlock
we must see the block hash and the txids included into the blockFor log analysis this lets us correlate the new block hash with the txs that were included into it. From there on we can trace the block hash.
For unrelated reasons we must also trace at default log level:
TraceNoLedgerState
TraceNoLedgerView
TraceBlockFromFuture
TraceDidntAdoptBlock
TraceForgedInvalidBlock
These are all rare, but possible failures. These should be logged at "Error" level, not just "Warning".
The text was updated successfully, but these errors were encountered: