Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TweetService.{post|like|retwett|...} do not propagate error responses from Twitter API #631

Open
tjanczuk opened this issue Oct 18, 2024 · 1 comment

Comments

@tjanczuk
Copy link

ACTUAL

When a call to TweetService.post(...) results in an error from the Twitter API indicating the request was rejected due to quotas, e.g.:

{
  "errors": [
    {
      "message": "Authorization: You have reached your daily limit for sending Tweets and messages. Please try again later. (344)",
      "locations": [
        {
          "line": 18,
          "column": 3
        }
      ],
      "path": [
        "create_tweet"
      ],
...      

The TweetService.post API simply returns undefined.

EXPECTED

When the requested action cannot be performed for whatever reason (authentication error, throttling), I'd expect the TweetService.post API to throw an Error with enough information about the root cause for the app to make an informed decision about how to proceed. For example, the app may want to implement retries with exponential backoff for throttling errors.

NOTES

This is similar to #611

@Rishikant181
Copy link
Owner

Rishikant181 commented Oct 19, 2024

Thanks for the feedback.

Unfortunately, no implementation of handling of errors thrown out by Twitter exists currently. The library only provides parsed data and nothing else. I know it's dumb but error handling has been on the backlog for quite some time, mostly due to the fact that the Twitter API throws some errors as a fetch error (which can easily be handled while making the request), while at other times, although the fetch response shows 200 (success), but an error exists in the response body. As a result, the error handling becomes somewhat convoluted and I could never come up with an "elegant" solution.

I'll try to handle it somewhat now, even if with a crude solution. Any input is appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants