Repository navigation
Tests fail on master due to Twitter API #7369
Description
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)
Activity
mtrezza commentedon Apr 24, 2021
This seems to be a temporary Twitter API issue, see comment.
dblythy commentedon Apr 24, 2021
Ok. So you would suggest wait until Twitter fix this issue on their end?
mtrezza commentedon Apr 24, 2021
Do we already know for sure that it's a Twitter issue?
You wrote:
That is confusing. The original endpoint returns a config object.
dblythy commentedon Apr 24, 2021
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 commentedon Apr 24, 2021
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 commentedon Apr 24, 2021
Yes, the original endpoint used to return that object. It returns an empty page right now.
mtrezza commentedon Apr 24, 2021
Even if it returned an object, the test still wouldn't pass, see the example response.
dblythy commentedon Apr 24, 2021
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 commentedon Apr 24, 2021
That is what I doubt. How could it have passed the test? I want to make sure we don't overlook something here.
dblythy commentedon Apr 24, 2021
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 commentedon Apr 24, 2021
I think we are talking about different aspects of this issue 🙂
Let's break it down:
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.
We could just care about (b) and close the book, but if we understand (a) we may actually find an additional issue.
mtrezza commentedon Apr 24, 2021
@dblythy You were right, I looked into this and I understand now that these endpoints are just random endpoints to test the failing auth.
It doesn't matter which endpoint is used as long as it requires OAuth. That confused me, I assumed these specific endpoints were picked for a particular reason, but they were just randomly picked. The test is now failing because of a Twitter API issue it seems, where the endpoint without proper auth does not respond with an error JSON, but with a zero length response, which is not expected by the test. The solution is just to switch to any other GET endpoint that requires OAuth end responds with an auth error JSON as expected.
I will comment on your PR.
dblythy commentedon Apr 25, 2021
Sorry, I should've explained that to start. My mistake for not being clear enough!
mtrezza commentedon Apr 25, 2021
No worries, I found the invalid endpoint in the PR, so the research was worth it. Thanks for tackling this issue to swiftly!