Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Error: version mismatch: expected v6, found v5 #1071

Closed
mitra42 opened this issue Nov 12, 2017 · 12 comments
Closed

Error: version mismatch: expected v6, found v5 #1071

mitra42 opened this issue Nov 12, 2017 · 12 comments
Labels
exp/wizard Extensive knowledge (implications, ramifications) required help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws)

Comments

@mitra42
Copy link

mitra42 commented Nov 12, 2017

  • Version: ipfs v26
  • Platform: OSX

Type: BUG

Severity: Critical

Description:

The latest version of JS-IPFS seems to be incompatible with the default swarm being recommended and generates the error version mismatch: expected v6, found v5

Steps to reproduce the error:

Set package.json to have ipfs: "^0.26.0" or "git+https://git@github.com/ipfs/js-ipfs.git"

Work around

Get the old version "git+https://git@github.com/ipfs/js-ipfs.git#319c1c9830262ab5c05bf99fc525d8883d3178cb",

It seems that JS's upgrade doesn't match the default swam - or at least the version of config Kyle gave us:
IPFS options :{"repo":"/tmp/ipfs_dweb20171029","config":{"Addresses":{"Swarm":["/dns4/star-signal.cloud.ipfs.team/wss/p2p-webrtc-star"]}},"EXPERIMENTAL":{"pubsub":true}},

While I have a workaround I think this is critical, because any app that updates to the IPFS v0.26 (e.g. just by running npm update) is going to break their app.

@mitra42
Copy link
Author

mitra42 commented Nov 12, 2017

Note, I added this at first as a comment on ipfs/kubo#4250 which maybe a different cause, and anyway the problem/workaround occurs in JS

@richardschneider
Copy link
Contributor

this may help ipfs/js-ipfs-repo#152

@daviddias
Copy link
Member

This is correct for js-ipfs master, it should not be for js-ipfs 0.26 as deps are locked with semver. Are you sure you didn't install deps once and then switched the version? Check package-lock.json

The solution @richardschneider pointed out is correct, right now it is just a question of a version number that doens't mean anything for JS land for this specific version update.

Cleaning up the old repo and generating a new one should also fix it :)

@mitra42
Copy link
Author

mitra42 commented Nov 12, 2017

David - sorry, I don't understand your first paragraph.
What I was doing, was switching the line in package.json, running npm update and then bundle. The changes were consistent, i.e. going between versions always had the effect expected (failure to start IFPS in anything except the version shown.

I'm unclear what you mean about "cleaning up the old repo" - whose repo? Mine or IPFS's and what do you mean by "clean" it.

I can confirm tnow that switching package.json to ipfs: "^0.26.0" works again.

@daviddias
Copy link
Member

I'm sorry, I should have been clearer. Let me explain again:

  • js-ipfs 0.26.0 and all of its dependencies were released with semver locked on patch version updates (the ~), which protects it from any breaking changes that might happen on minor versions, something that would not happen if we used the ^. Installing js-ipfs from npm should always be fine or at least that is a promise I work really hard not to break and if that happens, it should be handled as a big fire 🔥 that needs to be put out quickly.
  • In the way that npm works and due to js-ipfs giant dependency tree, I personally do not recommend to install modules individually unless you know exactly what npm is going to do. My recommendation is that everytime you want to experiment a new version, you update your package.json, you remove your package-lock.json and your node_modules forlder and then do a "clean" npm installs. Clean as it is a fresh install
  • The IPFS Repo is where the config including the version number is stored. I believe you had a similar issue in the past when we changed the webrtc-star multiaddr to p2p-webrtc-star, where js-ipfs was failing unable to parse the old multiaddr, right? If you clean (delete) your repo, js-ipfs will create a new one and make sure that the latest is up to date. This should be a last resort solution.

Sorry for the hiccups. js-ipfs 0.27 should be out the door in less than 2 weeks, any particular feature you are looking for?

@mitra42
Copy link
Author

mitra42 commented Nov 13, 2017

Thanks for clarification, I wasnt aware of this procedure requirement to remove package-lock.json before doing an npm update, usually I do an "npm update" before a bundle, just to make sure I'm testing against latest versions.

I"m not installing any IPFS modules individually only "ipfs: "^0.26.0. I do install Y modules individually, including Y-ipfs-connector.

Are you suggesting that package.json should include "ipfs: "0.26.0" in order to not update to 0.27.0, or that within ipfs you are using "" on dependencies to avoid complex dependency caused breaks?

Understood about cleaning repo, problem with that now is that anything I've "add'ed will get trashed since in most cases no-one will have that.

For 0.27 - three issues in order of priority:

The most critical thing from my perspective is the bad ongoing bugs.
#950 in particular is still a blocker for anything being released that uses JS IPFS since it crashes Firefox, and crashes the Chrome tab.

And #1049 which means that there is no possible way to retrieve half the files that are uploaded (via the HTTP API) from Archive.org (files.cat or dag.get fails on short (unsharded) files. That ones a big challenge because noone has even acknowledged we have a bug there despite its reproducability.

Third priority would be IPNS working in JS so we can implement naming things.

@kevingzhang
Copy link
Contributor

I am running IPFS 0.27, new fresh install, get the same error:
events.js:183
throw er; // Unhandled 'error' event
^

Error: version mismatch: expected v6, found v5
at get (/Users/kevinzhang/github/DAO/code/barenode/node_modules/ipfs-repo/src/version.js:57:27)
at store.get (/Users/kevinzhang/github/DAO/code/barenode/node_modules/ipfs-repo/src/version.js:31:9)
at /Users/kevinzhang/github/DAO/code/barenode/node_modules/graceful-fs/graceful-fs.js:78:16
at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:511:3)
[nodemon] app crashed - waiting for file changes before starting...

Any work around? or revert to install an older version?

@daviddias
Copy link
Member

@kevingzhang the simple workaround is to change the version number on your repo at ~/.jsipfs/version

@kevingzhang
Copy link
Contributor

Thanks @diasdavid I got the work around from #270 like this
const ipfsOptions = {
repo: './path/to/another/dir',
EXPERIMENTAL: {
pubsub: true
},
}
it works now

@olizilla
Copy link
Member

olizilla commented Dec 11, 2017

@diasdavid I'm seeing this after updating js-ipfs from 0.26.0 to 0.27.3

background.js:63 Unable to initialize addon due to error Error: version mismatch: expected v6, found v5
    at get (background.js:55221)
    at store.get (background.js:55195)

with a pretty minimal config:

  node = new Ipfs({
    config: {
      Addresses: {
        Swarm: []
      }
    }
  })

in ipfs-companion ipfs/ipfs-companion#320

I can remove my indexdb but i'll have to also get others who are reviewing this PR to do the same... should js-ipfs be auto-upgrading older repos?

@daviddias
Copy link
Member

@olizilla see #1115. tl;dr; we should have a utility to make devs life easier, until then it is up to the app developer.

@pgte developed this solution - https://github.com/ipfs-shipyard/peerpad-core/blob/master/src/backend/migrate-ipfs-repo-if-necessary.js

@daviddias daviddias added status/ready Ready to be worked kind/bug A bug in existing code (including security flaws) exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue exp/wizard Extensive knowledge (implications, ramifications) required and removed exp/expert Having worked on the specific codebase is important labels Jan 25, 2018
@alanshaw
Copy link
Member

alanshaw commented Nov 1, 2018

Lets track repo migrations here
#1115

@alanshaw alanshaw closed this as completed Nov 1, 2018
@ghost ghost removed the status/ready Ready to be worked label Nov 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
exp/wizard Extensive knowledge (implications, ramifications) required help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws)
Projects
None yet
Development

No branches or pull requests

6 participants