ipfs/kubo

Provide sentinel errors in the HTTP API

Open

#7,307 opened on May 12, 2020

View on GitHub
 (3 comments) (0 reactions) (0 assignees)Go (13,906 stars) (2,725 forks)batch import
P3help wantedkind/enhancementstatus/readytopic/rpc-api

Description

Matching errors against concrete types would be nice vs. fragile error string matching, e.g.,

if err.Error() == "'from' cid was not recursively pinned already" { ...

Or, maybe using more fine grained error codes would be even better. I believe the above error will come with a code: ErrNormal or similar.

Contributor guide

Tech stack
gorest api
Domain
backendapi
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Go basicsKubo HTTP API structure
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
60
Research direction
Investigate the current error handling in the Kubo HTTP API, specifically in files like `api/` or `commands/`. Look for places where errors are returned as strings and identify where sentinel errors can be defined. Consider adding new error types in a dedicated error package, and update all usages of fragile string matching to use these sentinel errors.
Provide sentinel errors in the HTTP API · ipfs/kubo#7307 | Good First Issue