Upgrade to 2.1.4 breaks S3 fileAdapter

[michaelbina]

I just upgraded my server to 2.1.4 and my fileAdapter seems to have broken. The files are now being pointed to my own server endpoint instead of S3.

My server config looks like:

  filesAdapter: new S3Adapter(
    process.env.AWS_ACCESS_KEY,
    process.env.AWS_SECRET_ACCESS_KEY,
    'whiterabbitapps',
    {directAccess: true}
  ),

I removed the fileKey config just in case that was interfering and that didn't fix the problem. Any insight into why this may have broken?

[asciimike]

@michaelbina which version were you upgrading from? FWIW, I think I'm seeing similar behavior in adapters not getting picked up in the server config (which would cause them to default back to the GridStoreAdapter and the behavior you're seeing here).

[michaelbina]

I was on 2.1.3

[asciimike]

Yeah, so looks like this issue is due to the changes made by adding AdapterLoader, see https://github.com/ParsePlatform/parse-server/blob/master/src/Adapters/AdapterLoader.js#L36

Since the S3Adapter is an object, it never gets returned, and instead gets swapped for the default object (which is GridStoreAdapter).

cc @flovilmart

[asciimike]

Looks like a quick and dirty fix is to change 35-37 to return the appropriate object if we're an object:

try {
  return adapter;
} catch (e) {
  return loadAdapter(defaultAdapter, undefined, adapter);
};

Not being the author, I don't have a good sense of whether or not this will break other adapters (which I assume are just objects), but the automatic behavior of "I got an object, immediately swap it out and try for a function" doesn't seem right to me (plus, when I swap it, the tests pass again!). Doing that, however, seems to throw a wrench in the gears, causing Push to have problems:

throw new Error("Adapter prototype don't match expected prototype"
{ send: { expected: 'function', actual: 'undefined' },
  getValidPushTypes: { expected: 'function', actual: 'undefined' } }

[Copyrightsworld]

Same issue here.
New uploads work ok and point to s3. Everything else is pointing to my own server.

Looking for a solution..

[Cliffordwh]

With this new version, how does one load it into the Json config to use the S3adaptor?

Im using ecosystem.json file that starts on pm2.

"apps" : [{
    "name"        : "parse-server",
    "script"      : "/usr/bin/parse-server",
    "watch"       : true,
    "merge_logs"  : true,
    "cwd"         : "/home/parse",
    "env": {
      "PARSE_SERVER_CLOUD_CODE_MAIN": "/home/parse/cloud/main.js",
      "PARSE_SERVER_DATABASE_URI": “*”,
      "PARSE_SERVER_APPLICATION_ID": “*”,
      "PARSE_SERVER_MASTER_KEY": “*”,
      "PARSE_SERVER_FILE_KEY": “*”,
      "PARSE_SERVER_JAVASCRIPT_KEY": “*”,
      "PARSE_SERVER_REST_API_KEY": “*”,
      "PARSE_SERVER_FILES_ADAPTER": “S3Adaptor”,
    }
  }]
}

But adding Files adaptor like this seems to break the server. Any advise on how to load the S3 adaptor and values on this new version 2.1.4?

[flovilmart]

@mcdonamp you are right, we expect the adapters to fail loading when the parameters are trying to get constructed with the wrong options. Which is not the case obviously.
Let me think of something.

[michaelbina]

I'm guessing I won't be able to get the fix to this until 2.1.5? I tried pointing to master in my package.json but then my server was completely broken, so I downgraded back to 2.1.3 for now. Is there a better way to point to the latest than:

"parse-server": "ParsePlatform/parse-server",

[asciimike]

That's the correct syntax for Git/GitHub URLs (per NPM docs).

That said, I would just use 2.1.3 until 2.1.5 comes out. While master should always be release ready, I wouldn't trust it. On a similar note, if you're running this for a production app, I highly recommend spinning up a staging server you can test against and run any upgrade on first, so if a regression like this manages to sneak into a release again, you can find and fix it without breaking production.