Skip to content

Parse.Cloud.httprequest fails to delete file with S3 adapter #7232

Open

Description

@mtrezza

New Issue Checklist

Issue Description

Deleting a file in Cloud Code via REST deletes the file from S3 even though it results in a 400 Bad request response:

await Parse.Cloud.httpRequest({
    method: "DELETE",
    url: 'https://example.com/parse/files/file.txt',
    headers: {
        'X-Parse-Application-Id': appId,
        'X-Parse-Master-Key': masterKey,
        'Content-Type': 'application/json'
    }
});

The http response is 400 Bad request, but the file is deleted from S3. This has been working before, but it doesn't anymore since some time (weeks, months?), not sure which change caused it to fail, it may even be something in the AWS S3 adapter.

Interestingly, it works without issue to delete the same file

  • with the same parameters via REST API outside of Cloud Code / Node.js
  • via Parse.File.destroy()

Because it works with a direct REST request, the issue may well be in Parse.Cloud.httprequest, therefore I post this as a Parse Server issue.

I have been debugging this down into the AWS S3 SDK, but I wasn't able to fully pin the issue. Looking at the Parse Server S3 adapter's deleteFile:

deleteFile(filename) {
  return this.createBucket().then(() => new Promise((resolve, reject) => {
    const params = {
      Key: this._bucketPrefix + filename,
    };
    this._s3Client.deleteObject(params, (err, data) => {
      if (err !== null) {
        return reject(err);
      }
      return resolve(data);
    });
  }));
}

It seemed as if each AWS S3 client method returns twice, once with a 400 response and once with the actual successful 200 callback. In other words, each of createBucket and deleteObject returns twice, but on the first return of createBucket, the deleteFile method returns, passing the 400 response to the original Parse.Cloud.httpRequest.

The Parse Server S3 adapter does not have Parse Server integration tests, and Parse Server does not test with the adapter, so I wasn't sure how to write a failing test case. Would be great if someone could try to reproduce this.

@dplewis You added the Parse.File.destroy method to the Parse JS SDK recently, maybe you came across something like this?

Steps to reproduce

  1. Use Parse Server S3 adapter.
  2. Save a file.
  3. Delete file in Cloud Code with Parse.Cloud.httpRequest as shown above.

Actual Outcome

Parse.Cloud.httpRequest should return correct response.

Expected Outcome

Parse.Cloud.httpRequest returns incorrect response, 400 instead of 200, even though the file is deleted from S3.

Failing Test Case / Pull Request

  • 🤩 I submitted a PR with a fix and a test case.
  • 🧐 I submitted a PR with a failing test case.

Environment

Server

  • Parse Server version: commit 2b9b336dd9d388ddb1b4099b87ff6a0d679199d7
  • Operating system: -
  • Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): local and remote

Database

  • System (MongoDB or Postgres): irrelevant
  • Database version: irrelevant
  • Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): irrelevant

Client

  • SDK (iOS, Android, JavaScript, PHP, Unity, etc): Parse JS SDK in Cloud Code
  • SDK version: 3.1

Logs

(none)

Activity

  1. dplewis commented on Mar 1, 2021

    @dplewis
    Member

    I personally don't use the Parse.Cloud.httpRequest. I use S3 so I can try to reproduce this.

  2. mtrezza commented on Mar 29, 2021

    @mtrezza
    MemberAuthor

    I would be curious to see if anyone could reproduce the issue.

  3. dblythy commented on Sep 14, 2021

    @dblythy
    Member

    In the docs, it states that httpRequest is supported for “legacy” reasons. It also hasn’t been updated in 3 years. Should we perhaps depreciate and recommend a dedicated networking option, such as axios

  4. mtrezza commented on Sep 16, 2021

    @mtrezza
    MemberAuthor

    I think it would be interesting if anyone could try to reproduce this issue. If that fails, we can just close this.

  5. dblythy commented on Sep 22, 2021

    @dblythy
    Member

    Related: #3837

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions