Parse.Object.saveAll() does not propagate sessionToken for all objects being saved

[rdbayer]

When calling Parse.Object.saveAll(array, {sessionToken: request.user.getSessionToken()}), only the first object would be saved successfully, while later objects would encounter an 'Object not found' error.

If I instead do a Parse.Promise.when where I save each object individually with the sessionToken, it works fine. Another workaround is using {useMasterKey: true} instead of the session token.

Neither of these workarounds should be necessary though.

[flovilmart]

Do you have server logs when running with VERBOSE=1 please?

[rdbayer]

Here are what I think are the relevant parts. Let me know if you're looking for something else.

Request

verbose: REQUEST for [POST] /parse/batch: {
  "requests": [
    {
      "method": "PUT",
      "body": {
        "status": 1
      },
      "path": "/parse/classes/UserTactic/GctM5PJpU0"
    },
    {
      "method": "PUT",
      "body": {
        "status": 1
      },
      "path": "/parse/classes/UserTactic/1QdvG2b2mE"
    },
    {
      "method": "PUT",
      "body": {
        "status": 1
      },
      "path": "/parse/classes/UserTactic/Pczihj8ACH"
    },
    {
      "method": "PUT",
      "body": {
        "status": 1
      },
      "path": "/parse/classes/UserTactic/cB6gmBgHpK"
    },
    {
      "method": "PUT",
      "body": {
        "status": 1
      },
      "path": "/parse/classes/UserTactic/P8PDqVdHwk"
    }
  ]
} method=POST, url=/parse/batch, user-agent=node-XMLHttpRequest, Parse/js1.9.2 (NodeJS 6.9.5), accept=*/*, content-type=text/plain, host=localhost:1337, content-length=652, connection=close, requests=[method=PUT, status=1, path=/parse/classes/UserTactic/GctM5PJpU0, method=PUT, status=1, path=/parse/classes/UserTactic/1QdvG2b2mE, method=PUT, status=1, path=/parse/classes/UserTactic/Pczihj8ACH, method=PUT, status=1, path=/parse/classes/UserTactic/cB6gmBgHpK, method=PUT, status=1, path=/parse/classes/UserTactic/P8PDqVdHwk]

Response

verbose: RESPONSE from [POST] /parse/batch: {
  "response": [
    {
      "error": {
        "code": 101,
        "error": "Object not found."
      }
    },
    {
      "error": {
        "code": 101,
        "error": "Object not found."
      }
    },
    {
      "error": {
        "code": 101,
        "error": "Object not found."
      }
    },
    {
      "error": {
        "code": 101,
        "error": "Object not found."
      }
    },
    {
      "success": {
        "updatedAt": "2017-03-23T23:51:36.110Z"
      }
    }
  ]
} response=[code=101, error=Object not found., code=101, error=Object not found., code=101, error=Object not found., code=101, error=Object not found., updatedAt=2017-03-23T23:51:36.110Z]

Extra Info

In case it helps, I should also mention that the context is that this is executing from within a cloud function (Parse.Cloud.define())

[Jeff2017]

Same here. I tried parse-server 2.3.2 and 2.3.7. I didn't use cloud code, just created a https server with databaseURI assigned to 'mongoldb://localhost:27017/parse'

save/saveEventually works fine for each one, but saveAll will save the first one and report 'Object not found' for others.

[flovilmart]

@rdbayer @Jeff2017 I just added a repro test case, and it doesn't seem to cause any issue (#3820)

https://github.com/parse-community/parse-server/pull/3820/files#diff-6bb28738fd55b13fe1590425946ed199R403

[rdbayer]

Whoops, sorry, made my previous (deleted) comment without reading the second part of your test :)

My only additional thought is that in my specific case, the ACL I'm relying on is for a Role, so maybe the bug is Role-specific?

[flovilmart]

Ah so you have a role then, not an ACL for a particular user right?

[rdbayer]

Yeah, to be even more precise, in my specific repro, the ACL allows permissions for role X and user Y, and the session token (that doesn't seem to get propagated correctly) is for user Z who has role X.

[flovilmart]

Updated the test, with User A with Role 'admin', and objects with role read/write, and still no issue. Even with an additional user having R/W on it.
Could you post some example data / a gist with an example that fails? I am not able to reproduce this issue.

[rdbayer]

I think the only difference left in my case is that the ACL also has read/write permission (for a user other than user A, in addition to the Role read/write permission), so perhaps that could somehow be causing an issue? But if that doesn't cause a repro, I'm out of ideas as to why I see it but you don't :-/

[flovilmart]

Do you have Class Level permissions or something else? Again, if you could post a gist with example data, that would help. I can confirm the session token is properly passed through, and propagated. The full auth state from the original request is actually propagated to the batch'd elements.