You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
objectstorage: make storage error descriptions extensible per backend #2661
Background #2614 added objectstorage.DescribeServiceError, which the in-tree object-store plugin uses to log a scrubbed description of an error it maps to Internal: the HTTP status, plus the service's code and message where the backend judges them safe (for GCS, the XML error's Code and Message, never Details). To keep that PR small, DescribeServiceError calls the GCS describer directly, then falls back to any error with an HTTPStatusCode() int method (e.g. S3 SDK errors) for the status alone.
Problem
The generic DescribeServiceError names a specific backend (GCS), so each new backend means editing it.
Every backend's describer runs regardless of which backend the plugin was configured with.
Go code outside this repo that imports pkg/objectstorage and adds its own backend can't plug in a describer.
Out-of-process third-party plugins log their own errors, so this is only about Go backends built on pkg/objectstorage.
Options
Describer on the configured backend: an exported interface, e.g. ErrorDescriber { DescribeError(error) (ServiceError, bool) }, implemented by the ObjectStorage client. The plugin asks only the backend it was built with, and external backends can implement it. A rough prototype passed tests but needs a typed field per plugin instead of any, and the Control plugin's objectstore.Store path would need the same.
Errors describe themselves: each backend wraps the errors it returns in a type implementing a describer interface. It's fully generic, but every error-return site has to wrap, and a missed site silently loses detail.
Activity