Mephisto Version Mismatch

[lidiyam]

Trying to resolve version mismatch when running parlai_chat_task_demo.

Installed mephisto using pip install -e ., pip installed parlai==1.7.1, followed the steps from https://mephisto.ai/docs/guides/upgrade_to_1/guide/ to update mephisto-task (npm list mephisto-task shows it's at [email protected]). So not sure where the mismatch is coming from.

Seeing the following on the server when the task link gets opened in the browser (http://localhost:3000/?worker_id=x&assignment_id=11)

[12/23/22 15:55:39] WARNING  [31;1m[Version Mismatch!!][0m: Package `mephisto-task` version mismatch. Expected version     client_io_handler.py:255
                             2.0.3 but frontend is currently using 2.0.2. This may cause unexpected errors, be sure to
                             update your `mephisto-task` dependency with `npm install [email protected] --save`. If this
                             warning still persists or the version isn't found, please open an issue at
                             https://github.com/facebookresearch/Mephisto/issues

And the following in the browser console:

Version mismatch detected! Local `mephisto-task` package is on version 2.0.2 but the server expected version 2.0.3. Please ensure you are using the package version expected by the Mephisto backend.

[JackUrb]

Hi @lidiyam - you may have some stale build files. Can you ensure there are no build files in either this or this directory?

[lidiyam]

@JackUrb removing stale files didn't help, same issue as before. I've manually verified all package.json files have mephisto-task at 2.0.3. Also found that this bit of code is what finds the 2.0.2 version:

export const libVersion = preval`
  const fs = require('fs')
  const file = fs.readFileSync(__dirname + '/../package.json', 'utf8')
  const version = JSON.parse(file).version;
  module.exports = version
`;

Which directory the __dirname refers to? The package.json in Mephisto/packages/mephisto-task has the right 2.0.3 version as well.

[JackUrb]

That should be pulling from the most local package.json for a given webapp at compile. @pringshia might know more about why your version isn't lining up here.

[lidiyam]

Same issue when running a task inside the Docker container (following https://mephisto.ai/docs/guides/how_to_use/efficiency_organization/docker/). Testing mephisto/examples/static_react_task also shows the same mephisto-task version mismatch when opening the task link.

[pringshia]

Hi @lidiyam, this is unusual behavior. I just ran the Docker container with static_react_task and was unable to reproduce this issue.

[lidiyam]

Hi @pringshia I'm still able to reproduce this, see the recording below: https://app.usebubbles.com/sKfStcGd1QdkJBEPyRwrU/mephisto-version-mismatch

It's not a blocking issue for running tasks and getting the data, but it happens consistently with all examples that I've tried running.

[pringshia]

Got it, thanks for the clarification @lidiyam. You may want to try removing all package-lock.json files from your Mephisto directory as such:

find . -name "package-lock.json" -exec rm -rf '{}' +;

and then trying again.

--

I also have a big PR landing hopefully soon that should bring some quality-of-life updates #905 ... perhaps that may also help resolve this transient issue

[Stefan1220]

Hi there, I got the same issue as well. I tried removing all package-lock.json files mentioned above, but it still doesn't work. Any idea about this?

[pringshia]

Hi @Stefan1220 - is your error message regarding the same versions? That is: Expected version 2.0.3 but frontend is currently using 2.0.2

[Stefan1220]

Hi @pringshia, it's reporting a different version after pulling the latest code. That is: Expected version 2.0.4 but frontend is currently using 2.0.3

[pringshia]

Ah I think I tracked down what the issue is. Our manual release deployment workflow ran the build (which encodes the current package version into the built source) before bumping up the version in the package.json when publishing to npm.

You can safely ignore this warning for now.

For the next 2.0.5 release, I'll plan on either switching to an automated deploy that will resolve this by sequencing the order of operations correctly, or add a prepublishOnly script to check this invariant when manually deploying.