Skip to content
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

Improve the node & faucet logs #484

Open
Mirko-von-Leipzig opened this issue Sep 5, 2024 · 4 comments
Open

Improve the node & faucet logs #484

Mirko-von-Leipzig opened this issue Sep 5, 2024 · 4 comments
Milestone

Comments

@Mirko-von-Leipzig
Copy link
Contributor

As evidenced in #483, our logs are missing useful context.

A lot of this context is going missing because we are using structured error enums which aren't encapsulating the inner error.

Common suggestion is to prefer anyhow for errors in an application as usually we don't care about the what, only that an error happened. For libs instead thiserror/structure errors are suggested but these are just guidelines.

In general, we should use anyhow if we don't care to match on the exact error variant.

@bobbinth
Copy link
Contributor

bobbinth commented Sep 6, 2024

Common suggestion is to prefer anyhow for errors in an application as usually we don't care about the what, only that an error happened. For libs instead thiserror/structure errors are suggested but these are just guidelines.

I think this is roughly how things work now, no? Basically, we use thiserror in the libs and use anyhow in the miden-node binary.

@Mirko-von-Leipzig
Copy link
Contributor Author

I think this is roughly how things work now, no? Basically, we use thiserror in the libs and use anyhow in the miden-node binary.

Correct; however these are just rough rules of thumb. The more accurate gauge is whether one cares about the error variants at all. Or put slightly differently - are our rpc, store and block-producer crates libraries, or are they just components on the node binary split into separate crates for organization/decoupling purposes?

Semantic games aside though, we just need to ensure that we don't lose any important context along the way. Something like anyhow makes that easier, but this is of course just as possible with thiserror or the other error types - just a bit more effort and care required. Though one does lose line info which could be helpful in logs.

@Mirko-von-Leipzig
Copy link
Contributor Author

Hmm now that I've logged on to the actual instance, the logs provided initially seem to be truncated.

Error: Failed to serve store: initialisation of the Api has failed: Genesis block error: Failed to read genesis file "./genesis.dat": No such file or directory (os error 2)

On site logs appear to be fine ito context so maybe this is a non-issue. Could be worth taking a look regardless.

@Mirko-von-Leipzig
Copy link
Contributor Author

Related to #499.

@bobbinth bobbinth added this to the v0.7 milestone Oct 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

2 participants