Twitpocalypse bug (will not import if twitter_id greater than 2,147,483,647)
| Project: | |
| Version: | 6.x-2.4 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Hi all. I hope I've pegged this problem correctly... else I'll never forgive myself for using a "word" like "Twitpocalypse"...
I noticed this weekend that the Twitter module had stopped importing new posts from Twitter. Sometimes this happens, so I hit cron manually to check if my automatic cron runs had choked on something -- nothing. Played with the import settings -- nothing. I deleted the entries from the database manually, hit cron, but it only imported up to the previous last tweet.
Then I remembered the Twitpocalypse. This event was supposed to occur after the number of Twitter posts exceeded the greatest value of a signed integer, i.e., twitter_id greater than 2,147,483,647. The last tweet in my database was assigned this value (even though the real tweet, when I view it on twitter.com, is 2,157,065,033).
So. I think something in the code is only posting the Twitter unique identifier to the database up to the maximum value of an unsigned integer. It's not in the twitter table itself -- the twitter_id field is a bigint(20), should be good until the sun turns into a cinder. It must be in the code (in twitter.inc?).
I'll poke around a little and see if I can find the problem -- if it is a problem, I might have this all wrong -- but thought I would mention it here in case someone more deft and knowledgeable than I could help.
#1
Just wanted to state that I've been having the same problem since the weekend. I uninstalled twitter and tried to reimport the posts but all it imports are posts up to the point when the problem first occurred.
EDIT: Just checked my database. The id of my last tweet is 2147483647, which corresponds to the twitpocalypse bug. I've also verified I'm on 6.x-2.4 and I re-ran the database fix (6003) in case to no avail.
#2
Exactly the same problem here. This problem started on Saturday. We upgraded to the latest -dev version (after uninstalling the module), re-submitted the Twitter accounts, but we received just a few new Tweets. We also noticed the latest Tweet being refreshed while the previous Tweets are the same.
#3
Can confirm that this is an issue we are seeing it on many sites utilizing this module.
-----------------------------------UPDATE----------------------------------------------------------------
After a little digging it looks like the returned XML tags have changed, the old ID field was called twitter_id now it is just id , this is throwing everything out of whack. All the views related exposure is also wrong.
posting patch now
RobbieTheGeek
#4
If it's not just me seeing the issue and the issue prevents the module from importing any new Twitter statuses, I think that's justification for critical priority...
#5
I am having this issue aswell, it only imports posts up to the point where the problem first occured.
#6
Patch to just copy the field from $status['id'] to $status['twitter_id'] in the cache function
-----------------------------------------------------------------------------------------------------------------------
working with Eaton at the moment. ^^^ lies :)
Robbie
#7
This is definitely troubling -- I'm running the current production version of Twitter.module on my blog and it's importing statuses without any problems. I'm absolutely not suggesting that the problem isn't real, but I'm also worried that there might be something under the surface (or platform-specific) that is at play. Does anyone have any information about their PHP environment? 32 vs 64 bit builds?
#8
I am also *not* having a problem. My site is pulling my latest tweets in just fine once I did the upgrade to 6.x-2.4. Just as a data point, I am using PHP 5.2.3-1ubuntu6.4.
#9
Just took a closer look - robbie, if that line isn't there in your code, what DOES appear in $status['twitter_id']? because the _twitter_convert_status() function on line 467 of twitter.inc should already be handling that:
function _twitter_convert_status($status) {$result = (array)$status;
$result['twitter_id'] = $result['id']; // This is already happening here!
if (!empty($result['user']) && is_object($result['user'])) {
$result['account'] = _twitter_convert_user($result['user']);
$result['screen_name'] = $result['account']['screen_name'];
}
else {
$result['screen_name'] = NULL;
}
$result['created_time'] = strtotime($result['created_at']);
return $result;
}
I'm investigating the possibility that the bolded line doesn't work properly on 32-bit PHP builds, but in that situation I don't see how doing the copy later, in twitter_cache_status(), would change anything...
#10
I just installed the Twitter module on a site that is on Media Temple DV server and it's working fine for me.
#11
Hi Jeff, thanks for the quick response and taking the time to look.
PHP: 5.2.5
Server: Apache/1.3.37 (Unix)
#12
FreeBSD 6.2
Apache 2.2.10
PHP 5.2.9
Drupal 6.12
Twitter 6.x-2.4
Still showing the same tweets from three days ago at http://www.brianshumate.com/
#13
The good news: I've just managed to duplicate this issue on a local install of Drupal with twitter module on a 32-bit compile of PHP. We're running into a known core bug that manifests on 32-bit compiles of PHP #333788: Cannot insert/update unsigned integers or numbers bigger than an integer. Because we don't actually do a lot of *number* work with the twitter_id, I'm going to convert it to a string. It's horrible and ugly, but it's the safest approach for now and won't make anything break too badly.
#14
The commit is here -- testing of the -dev 2.x branch would be appreciated before I roll a 2.5 release.
It also sneaks in a new Views field -- Status ID -- that makes testing this easier using a simple view.
#15
Have tested on 2 sites that were having the issue locally & this resolved it
Thanks for jumping on this sir.
RobbieTheGeek
#16
Thanks for the fix -- works fine for me.
#17
Can confirm this was rolled out for us and all is working fine.
Thanks again Jeff
Robbie
#18
Automatically closed -- issue fixed for 2 weeks with no activity.