Closed (fixed)
Project:
Twitter
Version:
6.x-5.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
26 Feb 2014 at 01:51 UTC
Updated:
17 Jun 2015 at 12:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
xurizaemonComment #2
xurizaemonAt this point, I think we need a co-ordinated solution, and the straightforward one seems to be moving everything back to integers, which I suspect would make this module dependent on JSON_BIGINT_AS_STRING and hosting on 64-bit architecture.
That is the approach put forward by #2055951: Interesting MySQL issue appears to cause randomish "twitter_views_handler_field_formatted_tweet->render()" errors, but that issue only addresses one field and there are several. I think that moving to storing as proper integers is the right step here, as the workarounds from related issues have not been sustainable.
It is likely that versions of PHP without JSON_BIGINT_AS_STRING and storage on 32-bit architecture may require community input / contribution for continued support.
Comment #3
xurizaemonComment #4
xurizaemonComment #5
tr33m4n commentedHmm, wish I had more skills to fix this for 32 bit arch. I'm just going to have to live with this problem for now then
Comment #6
xurizaemon@tr33m4n, TBH the odds are it'll be less work to migrate to a better hosting environment than for anyone to fix this. Unless there is either (1) a combined effort by many people who want to avoid an hour each migrating hosting platforms, or (2) a single contributor who has a massive investment in 32-bit hosting (?!?!). No-one seems to be putting their hand up for either.
Note that there are multiple discrete issues (PHP's json_encode and MySQL's storage) at play here.
Comment #7
adamps commentedOK, I'm not an expert here, but in the absence of a working solution so far, I've given it a go.
As far as I can see
The code as stands seems to work fine for twitter_id and in_reply_to_status_id, which have been way too big for an int for a long time. More recent twitter accounts now have user IDs too big for an int, so the same situation now applies to in_reply_to_user_id.
The main bug that I hit on 32-bit is #2142055: in_reply_to_user_id failing for IDs greater than 32 bit - causes cron to fail, which comes when casting in_reply_to_user_id to signed int making it negative.
So I think the fix is to copy the working code for the other two fields to in_reply_to_user_id. I have attached a patch that attempts to do this. So far it has survived limited testing on my dev server. I would welcome comments from anyone else, or feel free to test on your own dev server.
FWIW I would guess that the patch in #2142055 might well work from 2^31 up until 2^32 but will then fail at it's missing the PHP_INT_MAX magic.
Comment #8
adamps commentedComment #9
damienmckennaComment #10
rclemings commentedThe patch in #7 works for me on 32-bit CentOS6.
Comment #11
damienmckennaComment #12
damienmckennaComment #14
adamps commentedSorry my patch was against the stable code rather than dev - updated.
Comment #15
adamps commentedComment #19
adamps commentedTry again (sorry tweaked patch by hand and missed a bit)
Comment #22
damienmckennaFYI the tests should now be passing, so if it's reporting a problem then there might be an actual problem ;)
Comment #23
adamps commentedFixed it. This patch has been confirmed by @rclemings in #10 so I hope I'm not out of order to marked it as RTBC on that basis, and request commit - thanks.
Comment #25
damienmckennaCommitted. Thanks AdamPS!
Comment #27
damienmckennaFYI I ported the patch to 7.x-6.x.
Comment #28
damienmckennaBackported to 6.x-5.x.
Comment #31
damienmckennaLets try that again, this time on the correct branch.
Comment #33
damienmckennaCommitted. Thanks!