Retweets aren't sticking to timeline

restapi
php
retweet
api

#1

So I am using Abraham’s set of scripts to help on our site. Everything seems to work fine and as expected. But what I am finding is that an actually retweet that is done say today, via the API, doesn’t stick and seems to be gone off a user’s timeline say 5 to 7 days from now.

I’m wondering if anyone else has had this issue and what can I go about looking for to correct the issue? Our users don’t want to use a service that doesn’t allow a retweet to stick to their timeline after a certain period of time.

Here’s something else to add to the mix. A user authenticates their account via our system and we then use the API on their behalf to post a retweet that they place into our system. The only way the retweet gets posted to a user’s Twitter time line is through this process. When they successfully do - we also get the twitter id back from Twitter (in json) and store that id for later usage. When I check that retweet id, it is in fact a valid id and I can see all the data in a json response about the re/tweet. But the only thing is, if it’s a couple of days old, then the retweeted = 1, but if it’s anything passed say 5 to 7 days - retweet = {blank} Meaning not retweeted. But yet the actual data is returned in a json response about that retweet id.

So it’s left me completely baffled as to what I should be looking for in order to correct the issue and make it stick. Again, there’s no problem with the “outbound” retweets - it’s only after they have sat for a while they disappear from Twitter and the user’s timeline.

Any thoughts or insight is appreciated. I really need to get this resolved so that we don’t start losing customers because of this.


#2

@bonnell @andypiper Any thoughts on this?


#3

I’ve been using Abraham’s script as well. Just checked a few of the retweets done through my application with it and they’re all still there. It doesn’t make any sense as to why they would randomly disappear. When you view the original tweet on Twitter does the account that should have retweeted it show in the list of retweeters?


#4

@DanielCHood yes, the original tweets are there, shoot even the original retweet id and it’s data is still there, just retweeted response isn’t set. Like I said, I know for a fact it went out - that’s how I originally got the retweet id to begin with.

If need be, I can pastebin a response and show an example based on a retweet id I have in my system. When you see the json data it will show everything about the retweet, even the original tweet’s information, etc, but retweeted will have a blank value (meaning the retweet isn’t there).

Now it’s possible (as I am not perfect) that I may be misunderstanding the json data and it’s structure and such, but this system has worked for quite a while without any issues at all based on my previous understanding. So I don’t think that may be the case at all.

Let me know and I can pastebin an example for a fresh set of eyes to review.


#5

@andypiper Any thoughts?


#6

@bonnell Mike, is there any chance you could take a look into this for me?


#7

Unfortunately this is an area I know very little in @brandyellen


#8

Any suggestions on who could help figure out why retweets are sticking?

Also are you familiar with Twitter’s json response in regards to a retweet?


#9

Sure. Looking at a snippet of the code could help. Knowing one of the tweet IDs (and corresponding retweet id) could help as well.


#10

First of all let me just note that myself, @bonnell and other members of the team are unfortunately not able to cover every thread and question that is asked on the forums (particularly not always in a timely manner) - we have different skills and schedules - these are here for community support as much as as direct help from us :slight_smile: your patience is appreciated!

That said, this sounds super odd…

When you Retweet a status, the ID returned in the JSON is the Tweet ID of the new Tweet; the original ID is in the retweeted_status object inside it.

I don’t understand why a retweet would “disappear” unless that (new) Tweet ID is itself deleted or unretweeted later. Are there any other applications attached to the account that could be doing this?

Are you able to share specific Tweet IDs that demonstrate the problem you are explaining? Thank you.


#11

Ok understood, as I got in and read some more after I posted - I began to realize that each person has their specialties. I apologize for that.

As far as an id - let me give you an example

Here’s one that was used via the API:

[created_at] => Mon Dec 12 23:58:12 +0000 2016
[id] => 808460976836132865

That retweet went out via the scripting and the id was returned via the Twitter json response and then was stored. Now, when I attempt to pull up that status (retweet) in my Twitter time line which would be here:

That retweet would no longer be applied (meaning the double green arrows would be gray and not green)

As far as applications - there is only one app that is attached and our users authenticate through that app. The “only” feature we have is a single page that someone could click an “X” and delete that retweet from their timeline - but that isn’t something our user base does at all. These are a bunch of bloggers and VA’s and it’s their job to post retweets and not have them removed.


#12

@andypiper - Here’s a working example of what I am talking about:


#13

And the results of that id via a status lookup using the API says this:

[is_quote_status] =>
[retweet_count] => 172
[favorite_count] => 0
[favorited] =>
[retweeted] =>
[possibly_sensitive] =>
[possibly_sensitive_appealable] =>
[lang] => en

Specifically:
[retweeted] =>

But again, I got the id of the retweet via the API and code, which means it had to have successfully posted to Twitter via the code and API in order to have gotten the id of the retweet.

Like I said, after about 5 or 6 days or so - they seem to undo themselves. It’s completely strange.


#14

The retweeted value is what we call perspectival, i.e. it depends who you are, and will only show true if the authenticated user has RT’d the status you’re checking for.

As an example, I just used twurl to RT ID 808460976836132865 from one of my test accounts. Checking the status back with that same account, retweeted shows as true; changing to another account which didn’t RT it, and then retrieving the status, retweeted shows as false.

What you’re describing is that entering the RT ID into a browser essentially redirects you to the original Tweet (and a native retweet is basically just a reference to another Tweet) - again, the green RT arrows should only show if you have retweeted the status. The RT should show in the timeline of the user that RT’d it. You’ve got a lot of retweets in your timeline, so I wasn’t able to scroll all the way back for a week to check - certainly things look like they are working as expected based on all of the other content in your timeline, but you did mention this seems not to work past a week, which is odd. From an API / developer platform perspective, the Tweet object(s) themselves look fine.


#15

Ok, while I can understand what you’re saying, I guess that theory isn’t sticking true.

It’s completely understood that if I retweet a tweet and then login and look - I should see the double green arrow, and if I login to another account and see the same retweet - the double arrows won’t be green. That makes 100% sense and it’s how it should work.

But let me blow that theory out of the water in this scenario for a moment.

In this video - I share some simple code that gets the status of the user, shows that they properly authenticated via the API, and then gets the status of the ID in question. The end results shows that via the API - after I have retweeted this tweet using the API originally, the json response shows “false” on the retweeted variable. But when I go to twitter, click on retweet, and then come back to the API and refresh the page again, retweeted now shows 1 (true).

But it goes back to the original statement - the retweet was originally posted via the API and it gave me the retweet id in question in return - which means theoretically - if the id is returned via the API - it successfully retweets - thus providing the id. Otherwise it would have failed for whatever reason. (Retweeted already, over limit, etc)

I hope you can see why I am baffled with this.


#16

@andypiper Did you see this response?


#17

Yes but I have not had time to reply (and is past 1am here now) - again I’d ask you to respect that we are not all here or able to answer every thread. I don’t have an answer for you right now I apologise.


#18

It’s ok! Truly, I do respect that you have quite a bit going on. I’ve yet to be able to figure this out as to why they aren’t sticking. I’ve poured over what logs I have and ids and such. Still nothing. :confused:


#19

Just to set your expectation, I’m going to time out on being able to check further on this ahead of the Christmas break, so I’ll have to pick this up in January if the issue persists. At the moment I am unable to reproduce it (and it sounds like I’d need to programmatically reweet something a week in advance, and then go back and check if it was still showing as a retweet 7 days later, if I understand the issue you’re describing correctly).


#20

I can give you a list of working examples that have this issue going on - and their respective IDs if you’d like. Just let me know how would you like to receive the list (potentially respecting privacy)