Add logger for VSS #87
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
This is a clone of the `ldk-server` logger
tankyleo
force-pushed
the
26-01-logging
branch
from
b2bd20a to
7c84099
Compare
|
Based on #86 thought you'd want to take a look tnull given your past debugging sessions against VSS. |
| tokio::spawn(async move { | ||
| if let Err(e) = connection.await { | ||
| eprintln!("Connection error: {}", e); | ||
| warn!("Connection error: {}", e); |
There was a problem hiding this comment.
Is this recoverable? error then?
There was a problem hiding this comment.
We can recover using fn ensure_connected if this happens on one of our 10 long-lived connections to the database.
There was a problem hiding this comment.
let me know if you would rather use error here it is true that if this happens during startup we do not recover.
In case we fail during startup we do have the error!("Failed to start postgres backend"); messages at the error level.
rust/impls/Cargo.toml
Outdated
| tokio = { version = "1.38.0", default-features = false, features = ["rt", "macros"] } | ||
| native-tls = { version = "0.2.14", default-features = false } | ||
| postgres-native-tls = { version = "0.5.2", default-features = false, features = ["runtime"] } | ||
| log = "0.4.29" |
| auth | ||
| } else { | ||
| println!("No authentication method configured, all storage with the same store id will be commingled."); | ||
| warn!("No authentication method configured, all storage with the same store id will be commingled."); |
There was a problem hiding this comment.
I do start to wonder if we should only expose this behind a testing feature or cfg flag?
There was a problem hiding this comment.
Now only available via cargo run --no-default-features --features testing see below
| store: Arc<dyn KvStore>, user_token: String, request: GetObjectRequest, | ||
| ) -> Result<GetObjectResponse, VssError> { | ||
| store.get(user_token, request).await | ||
| trace!("handling GetObject request with store_id {}", request.store_id); |
There was a problem hiding this comment.
Is it worth logging truncated key values to give an indication what is being written/read?
There was a problem hiding this comment.
I want to be careful with logging what could be sensitive information. Won't the keys all be obfuscated anyway via SorableBuilder in LDK-Node ? If so an operator of vss-server wouldn't get much visibility into what is getting stored.
No only accessible via `cargo run --no-default-features --features testing`
3 participants
This is a clone of the
ldk-serverlogger