Twitpocalypse Announcement

83 views
Skip to first unread message

Matt Sanford

unread,
Jun 12, 2009, 1:23:09 PM6/12/09
to Twitter Development Talk, twitter-ap...@googlegroups.com
Hi all,

The overflow of the 32-bit signed integer value for status ids
(a.k.a "The Twitpocalypse" [1]) is fast approaching. The current
estimate is around tomorrow at around 11am GMT, or 3:00am Pacific time
in the case of Twitter. There is some discussion internally about
accelerating things so we'll be in the office and able to cope. Nobody
is their freshest at 3:00am, not to mention it would be nice to not
have apps broken throughout the weekend if one-person developer teams
don't notice. No decision has been made yet but I wanted to get
something out to you all so you know what's going on in the event we
decide to do this.

Thanks;
– Matt Sanford / @mzsanford
Twitter Dev

[1] - http://www.twitpocalypse.com/

Matt Sanford

unread,
Jun 12, 2009, 2:30:28 PM6/12/09
to Twitter Development Talk, twitter-ap...@googlegroups.com
Hello again,

The responses to @twitterapi and all discussions internally show
a preference to not waiting until the middle of the night. The current
plan is to force this issue at 21:00 GMT (2:00pm Pacific/5:00pm
Eastern for those in the US). This will let us make sure we have all
staff available in the unlikely event something goes wrong on our end.
We'll also be available when people who don't follow the twitter-dev-
talk list start reporting errors. While we did warn developers about
the Twitpocalypse I'm sorry we didn't think about setting a drop-dead
date and scheduling this previously. We'll keep trying to improve on
warnings like this.

Good night, and good luck.

Thanks;
– Matt Sanford / @mzsanford
Twitter Dev

Brian Gilham

unread,
Jun 12, 2009, 2:38:05 PM6/12/09
to twitter-deve...@googlegroups.com
Thanks for the heads-up, Matt!

2009/6/12 Matt Sanford <ma...@twitter.com>:


>
> Hello again,
>
>    The responses to @twitterapi and all discussions internally show a
> preference to not waiting until the middle of the night. The current plan is
> to force this issue at 21:00 GMT (2:00pm Pacific/5:00pm Eastern for those in
> the US). This will let us make sure we have all staff available in the
> unlikely event something goes wrong on our end. We'll also be available when

> people who don't follow the twitter-dev-talk list start reporting errors.

kosso

unread,
Jun 12, 2009, 2:43:41 PM6/12/09
to Twitter Development Talk
Just a heads up for British devs (and Matt) :

The UK is currently in 'BST' (British Summer Time) - meaning that the
Twitpocalypse will occur at 10PM. (GMT + 1)

@kosso

Cameron Kaiser

unread,
Jun 12, 2009, 2:49:19 PM6/12/09
to twitter-deve...@googlegroups.com
> Good night, and good luck.

@ttytter stands ready!

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- NetBSD - a devil of an operating system. -- Julian Assange -----------------

Andrew Badera

unread,
Jun 12, 2009, 2:50:13 PM6/12/09
to twitter-deve...@googlegroups.com
Should we be withdrawing cash and stocking up on bottled water, like Y2K?

J. Adam Moore

unread,
Jun 12, 2009, 3:08:48 PM6/12/09
to Twitter Development Talk
So do I just allocate as many bits as I can in my database to the id
field and hope that it doesn't ever run out? I'm confused why you just
announced that. Okay, so an overflow is happening. Is that your fault?
Is this fixable on your end, my end. Is this just for people who are
using 32-bit signed ints to store ids? Decide to do what? Roll it over
like an odometer or increase the field size? Forgive me for being an
idiot, but 'decide to do this' is just about vague enough to be
insulting. I was happily under the assumption that this problem was
considered long, long ago when the field size was initially chosen by
who I also assumed to be smart people.

Martin Dufort

unread,
Jun 12, 2009, 3:30:54 PM6/12/09
to Twitter Development Talk
Matt: Are you going to intentionally bump the tweet unique id sequence
over the 2.1B mark ?
I think this is a very good move to this now instead on letting it go
by over the weekend.

Thanks - Martin

Stuart

unread,
Jun 12, 2009, 4:06:42 PM6/12/09
to twitter-deve...@googlegroups.com
2009/6/12 J. Adam Moore <jadam...@gmail.com>:

>
> So do I just allocate as many bits as I can in my database to the id
> field and hope that it doesn't ever run out? I'm confused why you just
> announced that. Okay, so an overflow is happening. Is that your fault?
> Is this fixable on your end, my end. Is this just for people who are
> using 32-bit signed ints to store ids? Decide to do what? Roll it over
> like an odometer or increase the field size? Forgive me for being an
> idiot, but 'decide to do this' is just about vague enough to be
> insulting. I was happily under the assumption that this problem was
> considered long, long ago when the field size was initially chosen by
> who I also assumed to be smart people.

I read it as "we're considering skipping a bunch of IDs so we hit the
limit during today rather than sometime over the weekend. That way
there will be people at Twitter able to react to support issues that
might arise.

As for what developers should do I think it's pretty obvious. If
you're using a signed 32-bit integer to store tweet IDs you need to
change that ASAP because judgement day is coming!!!

-Stuart

--
http://stut.net/projects/twitter

briantroy

unread,
Jun 12, 2009, 4:18:00 PM6/12/09
to Twitter Development Talk
Matt -

Are we still on for 2pm Pacific? That is roughly 40 minutes out from
right now.

Please confirm for us we are still on (cause if we aren't I want to go
to the pool :) )

Thanks!

Brian Roy
justSignal

Steven Degutis

unread,
Jun 12, 2009, 3:45:46 PM6/12/09
to Twitter Development Talk
To clarify:

This problem only affects applications who use a "signed integer" (32-
bit C-library) type, or equivalent, to store the unique ID of tweets?
Or does it originate on your end, where we will get incorrect IDs
right off the bat?

-Steven Degutis

Matt Sanford

unread,
Jun 12, 2009, 4:22:59 PM6/12/09
to twitter-deve...@googlegroups.com
Hi there,

That is indeed what I meant. We are planning to skip some ids to
force the 2^32 change during business hours. Twitter itself should be
fine but I originally announced this to the list so people could make
sure they'll also be fine. There is no change to the format of
responses and the number will continue to grow upward. This was just
fair warning that you might have used the Rails default definition (or
some other method) that relies on signed 32-bit integers.
The 'decide to do this' part is deciding to do this now by
skipping ids rather than let it occur naturally 12 hours from now when
people have been up for 24-hours and might not be at their best. Let's
not allow the 'insulting' vagueness devolve into insulting tone,
please. We're working on co-ordinating internally to do this at 21:00
GMT but like all things involving groups of people we may run a little
late. Sometime after 21:00 GMT this is still planned. We'll update
@twitterapi when the exact time comes.

Thanks;
– Matt Sanford / @mzsanford
Twitter Dev

Martin Dufort

unread,
Jun 12, 2009, 4:24:01 PM6/12/09
to Twitter Development Talk
I think this is delayed. And also 21:00 GMT is 16:00 Eastern and 13
Pacific.
Please let us know when the move forward in time will happen.

Martin - www.wherecloud.com

Chad Etzel

unread,
Jun 12, 2009, 4:28:11 PM6/12/09
to twitter-deve...@googlegroups.com
On Fri, Jun 12, 2009 at 4:24 PM, Martin Dufort<martin...@gmail.com> wrote:
>
> I think this is delayed. And also 21:00 GMT is 16:00 Eastern and 13
> Pacific.

No,

EDT is GMT-400
PDT is GMT-700

-Chad

Martin Dufort

unread,
Jun 12, 2009, 4:31:41 PM6/12/09
to Twitter Development Talk
You are absolutely right. Forgot about daylight savings....
So looks like around 5pm EDT.

Martin
On Jun 12, 4:28 pm, Chad Etzel <jazzyc...@gmail.com> wrote:

Marco Kaiser

unread,
Jun 12, 2009, 5:27:09 PM6/12/09
to twitter-deve...@googlegroups.com
as the target time has passed about 25 minutes ago... when can we expect it to happen now?

Thanks,
Marco

2009/6/12 briantroy <brian.c...@gmail.com>

Dossy Shiobara

unread,
Jun 12, 2009, 5:35:05 PM6/12/09
to twitter-deve...@googlegroups.com
So, what do the Four Birds of the Twitpocalypse do? Will there be
awesome smiting once the Twittergeddon is upon us?

--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

Cameron Kaiser

unread,
Jun 12, 2009, 5:36:50 PM6/12/09
to twitter-deve...@googlegroups.com
> as the target time has passed about 25 minutes ago... when can we expect it
> to happen now?

The fuse got long on the Twitter bomb, it seems. :-P

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- If I am not for myself, who will be for me? -- Pirkei Avot -----------------

Doug Williams

unread,
Jun 12, 2009, 5:52:38 PM6/12/09
to twitter-deve...@googlegroups.com
Just an update, there is a lot of coordination that it takes to pull something like this off. We need the operations team to watch the servers and application. The services team to work closely with the ops folks to ensure that any problems on our end are properly tracked and fixed. And Matt is running around coordinating the entire effort.

That said, the deadline may slip a bit as we work to ensure that we've covered our bases, and that the engineering team is ready to react to unforeseen problems.

Doing what we can to keep the tweets flowing.

Thanks,
Doug

Martin Dufort

unread,
Jun 12, 2009, 6:22:10 PM6/12/09
to Twitter Development Talk
Best of luck to the Twitter Team with the jump forward.
Martin
www.wherecloud.com

On Jun 12, 5:52 pm, Doug Williams <d...@twitter.com> wrote:
> Just an update, there is a lot of coordination that it takes to pull
> something like this off. We need the operations team to watch the servers
> and application. The services team to work closely with the ops folks to
> ensure that any problems on our end are properly tracked and fixed. And Matt
> is running around coordinating the entire effort.
>
> That said, the deadline may slip a bit as we work to ensure that we've
> covered our bases, and that the engineering team is ready to react to
> unforeseen problems.
>
> Doing what we can to keep the tweets flowing.
>
> Thanks,
> Doug
>
> On Fri, Jun 12, 2009 at 2:36 PM, Cameron Kaiser <spec...@floodgap.com>wrote:
>
>
>
>
>
> > > as the target time has passed about 25 minutes ago... when can we expect
> > it
> > > to happen now?
>
> > The fuse got long on the Twitter bomb, it seems. :-P
>
> > --
> > ------------------------------------ personal:
> >http://www.cameronkaiser.com/--
> >  Cameron Kaiser * Floodgap Systems *www.floodgap.com*
> > ckai...@floodgap.com

Dan Udey

unread,
Jun 12, 2009, 4:52:04 PM6/12/09
to Twitter Development Talk
They're bumping it up so that if you're doing something silly (like
using an unsigned integer to store the ID), you can find out and fix
it. For an automatically incrementing ID, using a signed integer makes
no sense, so this is a good chance for shortsighted developers to find
and fix their bugs. An overflow will only happen if the developer of a
given app has made a careless mistake.

All Twitter is doing is triggering the event that will break careless
developers' apps on a Friday, instead of breaking careless developers'
apps on a Saturday.

J. Adam Moore

unread,
Jun 12, 2009, 5:05:18 PM6/12/09
to Twitter Development Talk
Got it. Use Java's BigInteger class for all the ID fields and don't
look back. :)

On Jun 12, 1:06 pm, Stuart <stut...@gmail.com> wrote:
> 2009/6/12 J. Adam Moore <jadammo...@gmail.com>:
>
>
>
> > So do I just allocate as many bits as I can in my database to the id
> > field and hope that it doesn't ever run out? I'm confused why you just
> > announced that. Okay, so an overflow is happening. Is that your fault?
> > Is this fixable on your end, my end. Is this just for people who are
> > using 32-bit signed ints to store ids? Decide to do what? Roll it over
> > like an odometer or increase the field size? Forgive me for being an
> > idiot, but 'decide to do this' is just about vague enough to be
> > insulting. I was happily under the assumption that this problem was
> > considered long, long ago when the field size was initially chosen by
> > who I also assumed to be smart people.
>
> I read it as "we're considering skipping a bunch of IDs so we hit the
> limit during today rather than sometime over the weekend. That way
> there will be people at Twitter able to react to support issues that
> might arise.
>
> As for what developers should do I think it's pretty obvious. If
> you're using a signed 32-bit integer to store tweet IDs you need to
> change that ASAP because judgement day is coming!!!
>
> -Stuart
>
> --http://stut.net/projects/twitter

Doug Aitken

unread,
Jun 12, 2009, 8:14:07 PM6/12/09
to Twitter Development Talk
We seem to be hanging good here I think.

They changed the time, the actual tweet was sent by @nk
http://twitter.com/nk/status/2147483649 its listed on http://www.twitpocalypse.com

On Jun 12, 10:36 pm, Cameron Kaiser <spec...@floodgap.com> wrote:
> > as the target time has passed about 25 minutes ago... when can we expect it
> > to happen now?
>
> The fuse got long on the Twitter bomb, it seems. :-P
>
> --
> ------------------------------------ personal:http://www.cameronkaiser.com/--
>   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com

Jef Poskanzer

unread,
Jun 12, 2009, 10:17:01 PM6/12/09
to Twitter Development Talk
On Jun 12, 2:05 pm, "J. Adam Moore" <jadammo...@gmail.com> wrote:
> Got it. Use Java's BigInteger class for all the ID fields and don't
> look back. :)

Actually the easiest solution is to leave the status ids as strings.
That's what I do in my three homebrew twitter clients and they are
working just fine.

kprobe

unread,
Jun 12, 2009, 10:19:38 PM6/12/09
to Twitter Development Talk
Having issues with getReplies returning status id's less than the
requested value. Anybody else?

Lakshman Prasad

unread,
Jun 13, 2009, 4:29:55 AM6/13/09
to twitter-deve...@googlegroups.com
Hi Matt,

Could you also let us know how you increment tweet numbers. It is not constantly linearly incremented from 1, is it. That would mean there are over 2 billion tweets in the system, which isn't.

mozTom

unread,
Jun 12, 2009, 11:34:01 PM6/12/09
to Twitter Development Talk
Dan,

If you're using an unsigned integer, you won't see problems until the
4.2billionth tweet. If you're using a signed integer (which you don't
need to, will there ever be NEGATIVE tweets?), you'll see it at the
twitpocalypse.

Thanks for playing.

- Tom

Naveen

unread,
Jun 13, 2009, 4:42:03 PM6/13/09
to twitter-deve...@googlegroups.com
All Tweetshrap users, please update "TwitterStatus" object to use "long" for
"InReplyToStatusId" property. Otherwise you will be getting overflow errors.
Reply all
Reply to author
Forward
0 new messages