Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking: Improving ErrNotFound #7074

Closed
hsanjuan opened this issue Apr 2, 2020 · 10 comments · Fixed by #8757
Closed

Tracking: Improving ErrNotFound #7074

hsanjuan opened this issue Apr 2, 2020 · 10 comments · Fixed by #8757
Assignees
Labels
topic/tracking Topic tracking

Comments

@hsanjuan
Copy link
Contributor

hsanjuan commented Apr 2, 2020

@Stebalien this is meant to hold a small async discussion about continuing ErrNotFound approach, for lack of a better place (would affect multiple repos).

We have done: ipfs/go-ipld-format#55

And now, roughly:

go-datastore has an ErrNotFound.

go-ipfs-blockstore sees those and turns them into it's own ErrNotFounds

go-blockservice sees those and turns them into it's own ErrNotFounds

go-merkledag sees those and turns them into the ipld.ErrNotFound that we fixed.

Two possible approaches:

  • A: Remove package-specific ErrNotFound for blockstore, blockservice and merkledag and use and bubble ipld.ErrNotFound{CID} from the blockstore. This reduces lines of code. At the top level (go-ipfs), check with errors.Is(error, ipld.ErrNotFound{}), where needed.

  • B:

    • Modify all ErrNotFound types in blockstore, blockservice, merkledag (and potentially datastore), to be able to include CID information and NotFound() method
    • Bubble errors directly without re-converting them on every module.
    • At the top-level, where it matters to verify something is a NotFound, check with errors.As() to see if what we got implements the NotFound() interface.
    • This is more righteous at the expense of some more, duplicated code.

For practical reasons, I lean towards A, given that Blockstore, blockservice, merkledag, ipld-format are almost like internal modules in the go-ipfs codebase, and then it would not be too crazy to consolidate on a single error type for this.

(of course I can bypass all this and just make go-merkledag work with the new ipld.ErrNotFound, but I thought I'd ask as this would all be quick to fix in one go, either way).

Thoughts?

@hsanjuan hsanjuan added need/community-input Needs input from the wider community need/review Needs a review labels Apr 2, 2020
@hsanjuan hsanjuan self-assigned this Apr 2, 2020
@bonedaddy
Copy link
Contributor

A sounds like best approach. I was updating some dependencies and found that the IPLD format update broke merkledag so I tried implementing the patch in a fork to push upstream and it's not as intuitive as before when it comes to handling the error.

For example https://github.com/RTradeLtd/go-merkledag/blob/fix%2Fipldformat/dagutils/utils.go#L100 this doesn't take a cid.Cid type so you have to do cid.Decode to get the CID to use in error checking, but the decode process also returns an error.

Bubbling this up, and not needing to do cid type conversion in top level could would be extremely helpful

@hsanjuan
Copy link
Contributor Author

hsanjuan commented Apr 2, 2020

Bubbling this up, and not needing to do cid type conversion in top level could would be extremely helpful

you can leave the cid empty too...

As a side note, don't be overly aggressive updating dependencies (patch version bumps are fine), but other than that I'd keep go-ipfs's go.mod as reference.

@bonedaddy
Copy link
Contributor

you can leave the cid empty too...

Didnt know that

As a side note, don't be overly aggressive updating dependencies (patch version bumps are fine), but other than that I'd keep go-ipfs's go.mod as reference.

Normally I dont but dependabot picked this the ipld format change in a PR and it failed so I was curious what it would take to get resolved.

@hsanjuan
Copy link
Contributor Author

hsanjuan commented Apr 7, 2020

Discussed with @Stebalien , we're taking approach A. We will merge go-ipfs-block-format with go-ipld-format in the future (keeping aliases for backwards compat), for added consistency.

@hsanjuan hsanjuan closed this as completed Apr 7, 2020
@hsanjuan hsanjuan changed the title Discussion on ErrNotFound approaches Tracking: Improving ErrNotFound Apr 7, 2020
@hsanjuan hsanjuan added status/blocked Unable to be worked further until needs are met topic/tracking Topic tracking and removed need/community-input Needs input from the wider community need/review Needs a review labels Apr 7, 2020
@hsanjuan
Copy link
Contributor Author

hsanjuan commented Apr 7, 2020

Ok, I am going to hijack this issue to track this effort.

@hsanjuan hsanjuan reopened this Apr 7, 2020
@hsanjuan
Copy link
Contributor Author

hsanjuan commented Apr 8, 2020

@Stebalien I request inclusion in 0.6.0 milestone.

@hsanjuan hsanjuan removed the status/blocked Unable to be worked further until needs are met label Mar 2, 2022
@hsanjuan
Copy link
Contributor Author

hsanjuan commented Mar 2, 2022

Behold, for we have finally moved away from raw multihashes and this has been unblocked!

@Stebalien
Copy link
Member

🐢 🏁

@BigLep BigLep linked a pull request Mar 10, 2022 that will close this issue
@BigLep BigLep added this to the Best Effort Track milestone Mar 10, 2022
@BigLep
Copy link
Contributor

BigLep commented Mar 15, 2022

@hsanjuan @Jorropo : I assume we're going to need to do a bunch of releases on so this can bubble up to go-ipfs.

I suggest we use the versioning suggestions/tooling here: https://github.com/protocol/.github/blob/master/VERSIONING.md

If help is needed with the versioning workflow, please discuss in IPFS Discord / #ip-productivity.

@hsanjuan
Copy link
Contributor Author

A small follow up for the tagging was on #8757 . This is now finally closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/tracking Topic tracking
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

5 participants