Improve debugging by adding error contexts about akd

[slawlor]

A good point to check into on this might be the log crate, there is already a capturing which occurs with each macro call (e.g. debug!(...)) that is capturing a lot of this information. You can check our own log implementations, but we're capturing exactly this kind of info (file, line, thread, etc).

Might be a good starting point to populating this error metadata

[slawlor]

Ah I meant looking at how they capture the file, line number, method, etc. Not actually relying on it, sorry!

[eozturk1]

The logs by the log crate are not displayed (except println!). We need a logger implementation (@afterdusk pointed this out!) in addition to the log crate -- maybe env_logger. And initialize it. Then we can get those logs.

[slawlor]

So I think logging is going to be the way to go here. I was looking into how this would be implemented, but we would need to redefine the error structures we pass around to also collect a "context" object and when an error is to be returned, append the context about module,line,file,etc. This means modifying every location where an error response is generated, and kind of goes against the "spirit" of Rust's Result<_,_> type (from what I'm reading).

We can do it, but I think utilizing the log crate more heavily is going to make more sense here. I did do a large cleanup of the error types and how they're propagated around to make more sense of them, but no context as of yet.

[eozturk1]

Yeah, +1 on using the log crate. With proper context and unique error messages, we don't need the file/line to be included. I guess the initial issue we should focus on is actually getting the logs using env_logger. Otherwise, if they aren't println! I can't see any logs.

[slawlor]

Yeah, +1 on using the log crate. With proper context and unique error messages, we don't need the file/line to be included. I guess the initial issue we should focus on is actually getting the logs using env_logger. Otherwise, if they aren't println! I can't see any logs.

Qq: Where are you seeing or not-seeing the logs? What are you looking at for log messages? The unit tests I guess? We might need to write a wrapper to initialize the log env in tests such that failures will show the log info

[eozturk1]

Unit tests. Mainly the console. It seems #168 does the initialization.