Tests fail on master due to Twitter API

[dblythy]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest version of Parse Server.

Issue Description

As discussed here, one test fails on master.

Steps to reproduce

Run test Should fail a GET request'.

Actual Outcome

Test should pass

Expected Outcome

Test fails

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: master

Database

• System (MongoDB or Postgres): both

Logs

Failures:
1) OAuth Should fail a GET request
  Message:
    Uncaught exception: SyntaxError: Unexpected end of JSON input
  Stack:
        at <Jasmine>
        at IncomingMessage.<anonymous> (/home/runner/work/parse-server/parse-server/lib/Adapters/Auth/OAuth1Client.js:3:462)
        at IncomingMessage.emit (events.js:327:22)
        at endReadableNT (internal/streams/readable.js:1327:12)
        at processTicksAndRejections (internal/process/task_queues.js:80:21)

[mtrezza]

This seems to be a temporary Twitter API issue, see comment.

[dblythy]

Ok. So you would suggest wait until Twitter fix this issue on their end?

[mtrezza]

Do we already know for sure that it's a Twitter issue?

You wrote:

The test is expecting a response of {"errors":[{"code":215,"message":"Bad Authentication data."}]}. When the path is changed to /1.1/oauth/request_token, the correct error is thrown.

That is confusing. The original endpoint returns a config object.

[dblythy]

No. I’m assuming it is as this issue has never been prevalent before(I.e every test has passed before) and the endpoint now returns an empty page regardless of IP, user agent, etc.

[mtrezza]

That means the test has always been using an incorrect endpoint?

That seems not possible because the existing tests checks for a specific response in validateCannotAuthenticateError, but that response is not returned by the endpoint according to the example response in the docs.

[dblythy]

That is confusing. The original endpoint returns a config object.

Yes, the original endpoint used to return that object. It returns an empty page right now.

[mtrezza]

Even if it returned an object, the test still wouldn't pass, see the example response.

[dblythy]

Even if it returned an object, the test still wouldn't pass

Sorry Manuel, I’m not quite sure I follow. The object returned by the Twitter oauth used to pass the tests, and now, does not. How would you suggest this be approached?

[mtrezza]

The object returned by the Twitter oauth used to pass the tests

That is what I doubt. How could it have passed the test? I want to make sure we don't overlook something here.

[dblythy]

I don’t think we overlooked anything. My theory is that as Twitter move to newer API versions, they are removing older endpoints, and these no longer work. Admittedly this seems a little strange, however I can’t understand why the exisiting endpoint would stop working (rate limiting still happens on new devices).

[mtrezza]

I think we are talking about different aspects of this issue 🙂

Let's break it down:

• a) Why has the test passed in the past?
  The previous endpoint returned a config object. The response does not contain an error key, because this is not an OAuth endpoint. The API did not change, it is still v1.1, and the test runs against 1.1, hardcoded in the URL. This test should have never passed, because the response does not contain an error key. We could just say, we don't care, but I want to make sure we understand what is going on, maybe there is an additional issue we discover.
• b) What is the actual test purpose and therefore which endpoint does it require? Your PR seems to make sense, it seems to be testing for a specific error in a failing OAuth response. Maybe your PR is correct after all, but how can we say for sure if we don't understand the context of (a).

We could just care about (b) and close the book, but if we understand (a) we may actually find an additional issue.