[pdm-devel] [RFC PATCH datacenter-manager] server: api: resources: use root cause for errors for remote fetching

Wolfgang Bumiller w.bumiller at proxmox.com
Wed Sep 10 12:19:51 CEST 2025


On Wed, Sep 10, 2025 at 10:31:52AM +0200, Dominik Csapak wrote:
> 
> 
> On 9/10/25 10:15 AM, Wolfgang Bumiller wrote:
> > On Tue, Sep 09, 2025 at 10:25:51AM +0200, Dominik Csapak wrote:
> > > when we can't reach a remote for any reason, we want to return the error
> > > as a string here over the API. Since most errors that can occur here are
> > > client/network related (wrong credentials, no route to host, timeout,
> > > etc.) converting this error directly to a string gives us
> > > errors like:
> > > 
> > > `client error (Connect)`
> > > 
> > > which is not really helpful most of the time.
> > > Instead if we use the `root_cause()`, we get the most underlying error
> > > 
> > > e.g.
> > > 
> > > `error connecting to https://0.0.0.0:8006/ - tcp connect error: No route to host (os error 113)`
> > > 
> > > which is much more helpful.
> > > 
> > > We could also think about printing the whole error chain, but in my test
> > > cases here this was not more helpful, e.g. i got two times the above
> > > `client error (Connect)` and once the root cause from above.
> > 
> > Curious, because from a quick grep, `client error (*)` comes from hyper.
> > Otherwise I'd say it may have been one our own error types or
> > one-too-many same `.context()` calls.
> > 
> > I'm still not sure this is a good idea though, as we may still lose some
> > useful contest. I wish anyhow had an easy method to just shave off a
> > single layer.
> > 
> > What if we do this, but first throw in a:
> > 
> >      tracing::debug!("{error:?}");
> > 
> > just so we still have the option to see everything if we need to?
> 
> just to clarify: you want me to use root_cause and additionally log the
> error into the debug tracing? (not returning the whole `chain()` here)

Yes. Log the complete error at debug-level but only return the root
cause.




More information about the pdm-devel mailing list