Documentation on error codes

Ideas & Suggestions DCS feature requests - voting
1

Each libuplink error code should be documented as a separate entity, detailing:

  • the technical meaning of the error code,
  • additional diagnostic information available (e.g. key or bucket name) and how to extract them from the error code,
  • whether a given error code represents a transient problem (e.g. an I/O error), a configuration problem (e.g. lack of permissions), a user code bug (e.g. wrong arguments), maybe a libuplink code bug (e.g. a failed assert).

Documentation of each API call available in libuplink should have a comprehensive list of error codes that an API call can return, detailing:

  • conditions required for this API call to return a given error code,
  • whether the error code is restartable for the given API call (ie. does it make sense to perform the same API call again),
  • what state are the objects on which the API call has triggered the error in (e.g. is it still possible to perform other API calls on that object, ).

Right now it looks like the current libuplink implementation makes it close to impossible to write high reliability software with libuplink or comply with Toubon Law.

2

Have you checked?
https://pkg.go.dev/storj.io/uplink#pkg-variables

3

This thread is a follow-up to littleskunk’s post here: Test plan for geofencing - #3 by littleskunk

Your link at least contains a (n incomplete?) list of error codes, but with no further documentation. Which is, I guess, a progress?

4

I think so. But I would ask the team

1 Like
5

We will take your suggestions into consideration for improving the documentation.
A github issue has been filed with your request.

1 Like