rss-bridge: TwitterBridge: Could not parse guest token
I’m seeing an increasing number of these in my twitter bridge feeds:
Error message: `Could not parse guest token`
It happens randomly and doesn’t seem to be specific to any one of my twitter feeds.
PHP error:
[15-Dec-2021 11:48:03 UTC] Exception: Could not parse guest token in /home/ubuntu/rss-bridge/lib/error.php:24
Stack trace:
#0 /home/ubuntu/rss-bridge/lib/error.php(42): returnError()
#1 /home/ubuntu/rss-bridge/bridges/TwitterBridge.php(570): returnServerError()
#2 /home/ubuntu/rss-bridge/bridges/TwitterBridge.php(548): TwitterBridge->getGuestToken()
#3 /home/ubuntu/rss-bridge/bridges/TwitterBridge.php(576): TwitterBridge->getApiKey()
#4 /home/ubuntu/rss-bridge/bridges/TwitterBridge.php(586): TwitterBridge->getApiContents()
#5 /home/ubuntu/rss-bridge/bridges/TwitterBridge.php(221): TwitterBridge->getRestId()
#6 /home/ubuntu/rss-bridge/bridges/TwitterBridge.php(241): TwitterBridge->getApiURI()
#7 /home/ubuntu/rss-bridge/actions/DisplayAction.php(135): TwitterBridge->collectData()
#8 /home/ubuntu/rss-bridge/index.php(38): DisplayAction->execute()
#9 {main}
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 13
- Comments: 17 (11 by maintainers)
I create a new PR #2414 which should finaly solve the issues.
We may need to start thinking about adding Twitter API v2 support:
https://developer.twitter.com/en/docs/twitter-api/tweets/timelines/introduction https://developer.twitter.com/en/docs/twitter-api/tweets/search/introduction
Error rate has been extremely elevated today, so if anyone needed to test against this intermittent issue, it would be a good time to gather your data. Pretty sure I’ve gotten more failed feed retrievals than successful.
I wandered into Twitter’s API forum, and there’s multiple topics on similar issues, i.e. unable to retrieve tokens, invalid tokens, etc. This post in particular had some findings on token lifespans.
https://twittercommunity.com/t/unable-to-obtain-new-access-token-by-using-refresh-token/164123/7
tl;dr it seems that if you request a new token before yours expires, you’re okay. Otherwise, you’re not. Given the nature of RSS-Bridge, I don’t know that this finding is particularly useful, beyond “yep, something’s broken.”
Twitter’s API status page shows “degraded performance” for the RESTful API. It also seems they don’t really use issue history at all. If I had to guess, all of this might be a load issue that Twitter either hasn’t addressed, or is expecting to pass on its own, i.e. they’re not going to address it.
I’ve been trying to treat either 403 or 500 as EAGAIN. Here’s why:
If we receive a 403, getting a new guest token and refreshing seems to always work.
If we receive a 500, there’s no cookie in the document body – everything else is there – and a refresh usually gets a valid guest token, which we can then use to retrieve the contents.
When retrieving the guest token, it’s always at the very end of the document. The document is just sometimes short and missing the last line.
So I’ve got code that loops 3 times with a usleep, and then returns error 503 instead of the default 500 to tell the RSS client to try again later. Assuming the clients are well written, that should be OK. Of course, 503 only matters if error output is http.
I’ve had to rewrite that code a few times, as I get a bit more information from Twitter every time, and I need to run it for a few days to be confident it’s fixed – or at least better.
I created PR #2396 which will continue to use old/cached guesttokens until we successfully got a new one.