First pass focusing on warn and info level logging. Couple debugs

[jferrant]

I have been tearing my hair out trying to compare across log lines without knowing what is a burn header hash vs stacks block hash vs consensus hash etc. This is a quick first pass to just print all the info as available in all warn and info level logs. I also did a few debug logs that were specifically standing out to me. I think we could cleanup a lot of log lines to only ever print these hashes annotated instead of inline as they are just a nebulous blob of bytes otherwise, but will leave that for a sep PR.

I might actually implement on top of this a trait for printing internal hashes for each object that holds them, but for now this seemed the quickest way to get it done and that might be overkill especially if the object contains parent hashes.

Note I didn't bother changing really much of the pre nakamoto lines. There are a few, but I avoided touching neon_node for example.

Closes #4922

[wileyj]

@ldiego08 - pinging you since i know we discussed this as a possible PR, perhaps you can help jacinta here?

[ldiego08]

@wileyj, sure! @jferrant, please feel free to let me know how I can help (or if I'm needed). I'll be looking at logging in general to see how it can be improved or messages made more helpful. This PR provides a good insight into where some pain points are.

[jferrant]

@wileyj, sure! @jferrant, please feel free to let me know how I can help (or if I'm needed). I'll be looking at logging in general to see how it can be improved or messages made more helpful. This PR provides a good insight into where some pain points are.

I think for me the biggest pain point has been the inconsistency throughout the code base concerning what block heights (is it the anchor bkock height? the stacks block height? the burn block height?) and what hashes get printed (is it a consensus hash? a txid? a burn block hash? or a stacks block hash?). They are often not annotated so I have to look at the code closely to see what I am actually printing rather than just the log itself. I think this was my first pass effort that prob could be cleaner in general. I think maybe adding some traits for printing this info might be good? such as a trait with a function
"print_block_info" which would print all internal object data regarding block heights and hashes. I just don't know if it should include things like "parent_block_hash" or only print those if manually specified? Of couse this will not account for the instances of printing this data that is individually passed into a function rather than an object, but it might help all the same.

Otherwise, I think there are instances where some log messages should includ more data than they do, but its not available because its been abstracted into a sep function. This would be harder to determine without looking at very specific messages and updating them on a case by case basis so I prob would not worry about these cases for now.

@kantai what do you think?

[kantai]

@kantai what do you think?

Yeah, I agree with all of that. I think there's a bunch of pain points when it comes to our logs, but one thing that's hard for people is just as Jacinta said, there's often kind of multiple relevant chain references at a log location: burn header hash, consensus hash, stacks block hash, block heights, etc., and not all logs do a great job conveying all of them. A related-ish pain point is that often relevant information will be scattered across multiple log locations when they could be combined into a single log invocation.

[obycode]

Looks like an improvement to me. 👍

[blockstack-devops]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.