Filter Stream returns invalid matching_rules

NitDef · 2020-12-10T21:47:33.812Z

I’m using sample code from

twitterdev/Twitter-API-v2-sample-code/blob/main/Filtered-Stream/filtered_stream.js

// Open a realtime stream of Tweets, filtered according to rules
// https://developer.twitter.com/en/docs/twitter-api/tweets/filtered-stream/quick-start

const needle = require('needle');

// The code below sets the bearer token from your environment variables
// To set environment variables on macOS or Linux, run the export command below from the terminal:
// export BEARER_TOKEN='YOUR-TOKEN'
const token = process.env.BEARER_TOKEN;

const rulesURL = 'https://api.twitter.com/2/tweets/search/stream/rules';
const streamURL = 'https://api.twitter.com/2/tweets/search/stream';

// this sets up two rules - the value is the search terms to match on, and the tag is an identifier that
// will be applied to the Tweets return to show which rule they matched
// with a standard project with Basic Access, you can add up to 25 concurrent rules to your stream, and
// each rule can be up to 512 characters long

// Edit rules as desired below
const rules = [{

This file has been truncated. show original

Issue that I notice is that the returned matching_rules does not match the results from

GET /2/tweets/search/stream/rules

matching_rule ID that I received from the stream: 1337137539379941400

matching_rule list that I received from the endpoint: ['1337137536435515392', '1337137539379941376']

thomascmost · 2021-08-23T22:19:30.759Z

This happens to me as well! Would love an update from someone at Twitter Dev Support

IgorBrigadir · 2021-08-24T01:39:08.666Z

Pretty sure it’s the same here:

Filtered stream matches rules I deleted Twitter API v2

This looks suspiciously like the 64 bit integer issue in JavaScript Twitter IDs | Docs | Twitter Developer Platform 1429888227234631700 would be: 1429888227234631707 in this case. How are you parsing the IDs?

NitDef · 2021-09-13T21:21:13.704Z

Sorry for the late update here. One thing that keeps bugging me here is the type difference. When I receive the record from the filter stream, the matching_rule’s ID seems to be a number (without quote around it). As comparison, data.id of the same response is wrapped with quotes.

{"data":{"id":"1437525241786425353","text":"Footage of the semi-final match of the inaugural women's Clear Currency All-Ireland T20 Cup, broadcast by Cricket Ireland, showed the dog running onto the pitch to intercept the ball during play 🐶\n\nToday's top stories: https://t.co/4ozTbgvoxl https://t.co/C2r238OUlZ"},"matching_rules":[{"id":1436114489988968481,"tag":"dog videos"}]}

While making add_rule request, the response looks like following:

{
  data: [
    {
      value: 'cats has:videos',
      tag: 'cats videos',
      id: '1437524638125346816'
    }
  ],
  meta: {
    sent: '2021-09-13T21:12:36.349Z',
    summary: { created: 1, not_created: 0, valid: 1, invalid: 0 }
  }
}

So I wonder if there is a type conversion error occurred somehow while forming the response here.

No JSON.parse() is applied while logging both response bodies, and I’m using request with configuration:

const request = _request.defaults({ baseUrl: BASE_URL, encoding: 'utf8', auth: { bearer: TWITTER_TOKEN }})

I think the current response only has id than the id_str that was suggested in the link that you posted. Wonder if it’s something that is WIP.

IgorBrigadir · 2021-09-14T00:27:47.294Z

You’re right:

"matching_rules":[{"id":1436114489988968481,"tag":"dog videos"}]

I think is a mistake in the API - it should be

"matching_rules":[{"id":"1436114489988968481","tag":"dog videos"}]

(as a string) to be more compatible. I haven’t noticed this myself - using python the ids parse correctly.

Maybe the best place to suggest an improvement is on GitHub - twitterdev/open-evolution: Open evolution proposals for the Twitter API