Twitpocalypse bug (will not import if twitter_id greater than 2,147,483,647)

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.

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.

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

I am having this issue aswell, it only imports posts up to the point where the problem first occured.

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

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?

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.

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...

I just installed the Twitter module on a site that is on Media Temple DV server and it's working fine for me.

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/

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.

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.

Have tested on 2 sites that were having the issue locally & this resolved it

Thanks for jumping on this sir.

RobbieTheGeek

Can confirm this was rolled out for us and all is working fine.
Thanks again Jeff

Robbie