Comments (7)
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
from akd.
Ah I meant looking at how they capture the file, line number, method, etc. Not actually relying on it, sorry!
from akd.
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.
from akd.
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.
from akd.
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.
from akd.
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
from akd.
Unit tests. Mainly the console. It seems #168 does the initialization.
from akd.
Related Issues (20)
- Add Functionality to Send Unsigned Requests to AWS for Auditing HOT 1
- Lincense terms are unclear HOT 4
- Crypto Configuration / CipherSuite Trait
- Unused epoch parameter in append_only_zks::get_membership_proof
- Create a directory organization table in the README.md
- Comments for a lot of public-facing items can be expanded on for more detail
- Adding more examples for usage
- Improving the "Overview" documentation to specify what AKD does not support
- Adding tests for auditor.rs
- Rename public-tests to public_tests HOT 1
- Extend test fixture generation to include lookup proofs, history proofs, and audit proofs HOT 1
- Features should be additive, don't use nostd feature, but use an std one instead HOT 1
- akd_client also needs a key_history_verify() function HOT 1
- Remove tools/sync_fork.sh HOT 1
- Consider dropping support for the akd_client library HOT 1
- Lookup and key history verification need to ensure that the versions returned do not exceed the current epoch number
- VRF draft update to RFC 9381 plus fixes
- Confusing behavior for NodeLabels and the get_bit_at() function based on label length
- Update configuration documentation for some cryptographic functions
- Eliminate stale markers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from akd.