'Favorited' reports as False even if status is already favorited by the user

[burnettedmond]

Currently API calls to GET search/tweets seem to be incorrectly flagging tweets with the key ‘favorited’ as False, even if the user has indeed favorited this status.

JSON response when attempting to test-create a favorite which is flagged incorrectly (with status code 403):

{“errors”:[{“code”:139,“message”:“You have already favorited this status”}]}

Manually browsing to the status using the web interface confirms that the tweet has been favorited already. AFAIK this behaviour seems to have begun as of today.

[Stocks_Live]

I have the same issue. If I favorite a tweet, the return by the API search (for user me) is always false and the favorite_count is actually increased.
Is there any developer at twitter looking at this basic issue?!
Thanks,
Ilam

[andypiper]

Is this always the case, for all users and tweets that you have tried? Are you able to provide a test case to help us to reproduce the issue?

[isaach]

Hi there, these “perspectival attributes” (ie. values which depend on the authenticating user) are not supported by the search/tweets endpoint. It’s noted in the documentation at https://dev.twitter.com/rest/reference/get/search/tweets.

[Stocks_Live]

Yes this is always the case. I implemented a twitter client inside Stocks Live (an iPhone app, there is a free version to check this issue out) and when I favorite any tweet “and refresh the search”, I get the favorite_count increased but the favorited flag is set to false. Test case is very simple, I just use the search API. The user is logged in obviously as the favorite action is properly done.

Thanks for the response!
Ilam

[Stocks_Live]

It seems it is not supported as you mentioned, but I can’t see this in the URL you mentioned.
This leads me to the question of how do I know if the user favorited this tweet so I can properly display a star to the user. So I have to issue a new query for the user favorite and then match what the user has with the search result!

Thanks,

[isaach]

In the documentation it does say

In API v1.1, the response format of the Search API has been improved to return Tweet objects more similar to the objects you’ll find across the REST API and platform. However, perspectival attributes (fields that pertain to the perspective of the authenticating user) are not currently supported on this endpoint.

Happy to consider changes if you think there’s a clearer way to make this limitation known.

[Stocks_Live]

Thanks for making it clear and thanks for any further work on this issue. This is making it difficult for twitter clients to show the favorited star marked appropriately (unless I am missing something). In Stocks Live, the best I can do now is to internally mark this tweet as favorited but I am not storing those tweet data, they will be gone with the next refresh (search). Is there an easier way to detect if this user favorited this tweet?
Thank you!
Ilam

[Stocks_Live]

@isaach, given that this is a known limitation, can we know if this will ever be fixed or how can we correctly display the favorite flag if the tweet is favorited by the authenticated user?

Thanks,

[isaach]

I don’t know of any plans to address the limitation. In the meantime there’s no great way to display favorited status in search results. You could use statuses/lookup to look up the IDs of tweets returned in search results, and use the favorited attributes in the return from that API call. You could pre-load the user’s favorites using favorites/list and cross-reference against them. Or you could accept the same limitation that our API has, ie. favorites are not marked in search results.

[Stocks_Live]

@isaach, since favorited_count got updated correctly from the search API, I don’t really see a good reason for this to be a “limitation”. Can we log a bug so we can track the progress or see what is the interest for certain bugs?
Thanks,
Ilam

[isaach]

The difference is that favorited_count is the same for everyone. favorited is not. That’s what makes it a “perspectival attribute”, and this endpoint doesn’t have support for perspectival attributes (ie. ones which vary from user to user).

We don’t currently have a public bug database where you can file things and track them. It’s an interesting idea, though.

[Stocks_Live]

Some attributes like followed are supported, it seems to be falling in the category of “perspectival attribute”.
I do hope that Twitter open their bugbase to all developers so we can vote on which bugs are important or not. It is like hiring the best product managers for free!