Bug/Problem with the display_text_range of an extended tweet without tweet text

[abargnesi]

Hello twitter community,

I have run up against what I think is a bug in the display_text_range value of an extended tweet when only leading @ mentions and a trailing URL is in the full_text.

The problematic tweet found is BarisanRajawali/status/777954621826342912:

...
"full_text": "@SobatRizalRamli @rajomalano @republikaonline @antaranews @BeritasatuTV @PKSejahtera @Gerindra @PDemokrat @MRomahurmuziy @VIVAcoid https://t.co/kAN1Tayn9e
"display_text_range": [
    131,
    130
],
...

Here the display_text_range should identify zero-length tweet text, but instead provides an invalid start and end range. I would expect the space (" ") character at index 130 to be the inclusive start and 130 to be the exclusive end of the range which would produce an empty string.

Can you confirm this is a bug? Am I misinterpreting the display_text_range in this example?

The full tweet is available here.

Thanks,
Tony Bargnesi

[andypiper]

Thanks - this is an interesting one! I’ll check with the team and get back when I have more to share on the logic here.

[TweetinviApi]

Hello there, how are you capable of receiving display_text_range from a stream.
When I connect to streams, I do not receive these info.

Here is my url : https://stream.twitter.com/1.1/statuses/sample.json?tweet_mode=extended
Regardless of the tweet_mode parameter I receive the same thing.

Thanks

[abargnesi]

The Streams API is starting to deliver tweets in compatibility mode (see here) by default. The tweet_mode request parameter seems to be only for the REST API.

The sample streaming API will occasionally yield tweets with an extended_tweet JSON key which indicates it is an Extended Tweet. There only seems to be a couple hundred Extended Tweets a day so far, but will likely increase with the number of supported twitter clients.

[andypiper]

The tweet_mode parameter is not valid for the Streaming API. The Streaming API contains both extended and compat representations of any Tweets for backwards compatibility purposes.

However, it is not clear from this thread whether the original poster consumed this Tweet from the Streaming API or via REST. I pulled the Tweet via the REST API personally

[andypiper]

Also, just to confirm that we are investigating this particular case and hope to have more news for you shortly.

[abargnesi]

These tweets (and all others) we are pulling via the Stream API (Firehose).

[andypiper]

Thanks for confirming! Either way, working on getting back to you on the unusual Tweet you reported!

[andypiper]

Hey @abargnesi - thank you for your keen eyes here. With any change of this magnitude, edge cases are inevitable, and this was one of them. We’d like to thank you for spotting this and bringing it to our attention, and to apologise for our oversight.

If you retrieve the same Tweet now, you’ll see:

  "display_text_range": [
    130,
    130
  ],

This more accurately reflects the intent of our API changes, and we apologise for the “-1” indexing for a short while there! Whoops!

[abargnesi]

Thank you @andypiper and twitter team. Very quickly fixed!

[andypiper]