Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

Fix/err code #10

Merged
merged 4 commits into from
Sep 20, 2018
Merged

Fix/err code #10

merged 4 commits into from
Sep 20, 2018

Conversation

jacobheun
Copy link
Contributor

@jacobheun jacobheun commented Sep 12, 2018

Required by ipfs/js-ipfs#1557

This leverages the upcoming update to interface-datastore, to use consistent error codes, in order to better handle not found errors from the various databases available to ipfs users.

Once all the releases mentioned in js-ipfs#1557 are completed, all datastores will provide the same code when .get yields a not found error.

I also added an additional check of the result so that we don't attempt to create a CID in the event that a different error is returned from the database and result is null/undefined.

Note: This is not dependent on any other PR, however, if users get this update and not the datastore-level update (or vice versa), ipfs/js-datastore-level#10, they'll get an error if their mfs root doesnt exist yet.

@ghost ghost assigned jacobheun Sep 12, 2018
@ghost ghost added the in progress label Sep 12, 2018
@achingbrain
Copy link
Collaborator

Just seen this, sorry for the delay. You could do:

if (error && (error.notFound || error.code === 'ERR_NOT_FOUND')) {

to decouple this change from the dependency on ipfs/js-datastore-level#10 being merged & released, then remove the error.notFound at a later date once the js-datastore-level change has been released.

Otherwise LGTM.

@jacobheun
Copy link
Contributor Author

jacobheun commented Sep 19, 2018

Ah yes, that would be a good approach. No worries about not seeing this, I was waiting on some other releases to happen first before I added you as a reviewer to get it on your radar. I just updated that, so it should be good to release this safely.

@jacobheun
Copy link
Contributor Author

@achingbrain this should be good to merge and release when you have time. Thanks!

@achingbrain achingbrain merged commit 52c465f into master Sep 20, 2018
@ghost ghost removed the in progress label Sep 20, 2018
@achingbrain achingbrain deleted the fix/err-code branch September 20, 2018 17:37
@achingbrain
Copy link
Collaborator

Just trying to release this - is the upgrade to interface-datastore@0.5.0 necessary? js-ipfs depends on version 0.4.2 so you end up with two versions in node_modules, consequently instanceof on this line fails.

@achingbrain
Copy link
Collaborator

I really wish we'd release v1 of these things.

@vasco-santos
Copy link
Contributor

@jacobheun and @achingbrain

I think that we should use the class-is for type checks, which is already been used across many IPFS repos to prevent this problem.

References:

js-ipfs#938#issuecomment-373926328
js-ipfs#1310

@vasco-santos
Copy link
Contributor

@achingbrain regarding the line failure, I made a PR that fixes it yesterday

ipfs/js-ipfs#1558

But we should change things to that class-is when possible

@jacobheun
Copy link
Contributor Author

So, we can move the interface-datastore version back to 0.4.2 to get tests passing here, but we're going to hit failures for ipfs/js-ipfs#1558. I reverted to 0.4.2 and tested against that ipfs branch and got the same instanceof failure, as some modules are already updated to 0.5.0.

We should upgrade interface-datastore to add class-is, but we are going to hit the same problem until everything creating and checking keys are using class-is supported versions. We'll likely need to release a patch for the interface-datastore 0.4.x line to make this easier.

I think we can revert to 0.4.2 here, and handle the incongruities in the ipfs/js-ipfs#1558 PR. Does that sound reasonable @achingbrain @vasco-santos ?

On a general note, I agree that it would be nice to start using major versions more prevalently. I also would like to see us transition to not using modules we are a dependency of in our base test suites. I think it's great for running pre-release tests to make sure we're not breaking things, and upgrading major versions if we are, but as a baseline for tests it makes upgrading the dependency a huge pain. We do this a lot with IPFS and anytime we have multiple modules using a single dependency it ends up being a nightmare to release and have ci passing.

@achingbrain
Copy link
Collaborator

I think we should just wait for ipfs/js-ipfs/pull/1558 to be merged, then we can release this as a new minor so @alanshaw can control when it goes out with js-ipfs. The interface-datastore@0.5.0 upgrade will have to happen eventually.

@jacobheun
Copy link
Contributor Author

I've tested this code against js-ipfs#1558 and both of these against the s3 custom datastore. That should be fine, but tests here will fail until this module is pulling in a version of ipfs that has the #1558 updates.

@vasco-santos
Copy link
Contributor

yeah, I agree with waiting for ipfs/js-ipfs/pull/1558 to get merged and then update here

@alanshaw
Copy link
Contributor

Unblocked 🏇💨

@achingbrain
Copy link
Collaborator

Hooray!

@achingbrain
Copy link
Collaborator

@alanshaw are you doing a release with ipfs/js-ipfs#1558 in it?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants