Since this has been known about, literally, for months, why didn't twitter setup a mock testing environment that generated this potentially problematic case, allowing twitter app developers to test in a sandbox and release a new version before the 11th hour occurs?
I'm guessing it'd be far easier to have developers just a) check their database schemas and code, and/or b) to multiply all incoming IDs by 10, than for Twitter to setup a separate mock environment.
I can't imagine the logistical nightmare of having to replicate their staging environment, with the caching and message queue systems. It probably isn't `cp -r staging/ sandbox/` :-/
The mock environment doesn't need to do anything other than accept all inputs and produce known outputs (presumably some with known error conditions). This can often be implemented using apache rewrite rules/aliasing and static content served with the correct MIME types. I've set up mock servers for my own testing of public APIs when I want more control over monitoring my application than using a remote service would allow. You make a request once to the real service, store the content in a file on your own web server, and change your app to hit your server rather than the public, remote API.
