Twitter Stream disconnecting with code 6

[dcstrawson]

Hi -

We are getting repeated disconnects from the streaming API with the follow event preceding:

{“disconnect”:{“code”:6,“stream_name”:"###############",“reason”:“token revoked for userId #########”}}

Does anyone know what code 6 really means? The user Id mentioned are different each time, they are not our own user ids, the stream re-connects and carries on working. We are not using the user id specific stream options - we just use track.

I cannot find a reference to the meaning of the code, and who’s userid it is referring to.

[andypiper]

That sounds really strange. Can you confirm the endpoint you are hitting, and the query you’ve used? You mention track - are you also using the follow parameter?

[dcstrawson]

Hi - thanks for responding. We are using Twitter4J so I’m going to need to do some work next week to get you accurate answers on this, the following is assumption. My understanding is that we are using the ‘statuses/filter’ API and we aren’t knowingly using the follow parameter, that had occurred to me as possibly something to do with it and I checked, we definitely just use track parameter.

I’m sure you don’t want to deal with third party libraries, but just in case you do our code is something like this:

        (import Twitter4J v 4.0.7)
        TwitterStream twitterStream = new TwitterStreamFactory().getInstance();
        twitterStream.setOAuthConsumer(... , ...);
        twitterStream.setOAuthAccessToken(token);

        FilterQuery filterQuery = new FilterQuery();
        String[] filters = configFactory.getConfiguration().getStringArray("filterterms");
        filterQuery.track(filters);
        ...    
        twitterStream.filter(filterQuery);

Hope that makes sense - I’ll take a look next week in detail and check that is definitely the API that is being used.

[andypiper]

Yep this makes sense - error code 6 corresponds to the error message and reason string you are seeing (disconnect, on the basis of “token revoked for userId”) - but at present I’m not certain what condition would cause this, and I’ve personally not come across it before.

[andypiper]

I’ve done some more digging on this.

The user Id mentioned are different each time, they are not our own user ids

This error would be expected if you were connected to the stream using a user token that was subsequently revoked (most likely in the user’s application settings, or for example if the user account was suspended). You’re indicating that you’re not using tokens from the users referred to in the error messages?

[dcstrawson]

Hi Andy - sorry for the delayed response, thanks for your help its definitely appreciated. We definitely always intend to use the same token when we access the feed. The stream is a consumed in a stand alone process with a configuration file that contains the access token that we should be using. We always use the same token, and we don’t handle tokens that correspond to users inside this module. We are confident that the error is coming from that process.

However, we have checked some of the user ids that are reported and they do all correspond to our users - these will all be accounts that we have logged into our service using “login with Twitter”. But we don’t store the authtoken in the long term - we issue the client with our own token instead and throw away the original authtoken provided by Twitter.

I’m trying to come up with possible ways in which the our connection to the twitter stream API could be getting hold of one of these authtokens. As you say, this does seem to be what’s going on.

Here is what I have so far that could be causing this…

1. Twitter4J library is somehow replacing the authtoken we are providing with one of these 3rd party tokens. This can - as far as I can see - only be possible if there is an API within Twitter that allows us to ask for a list of authtokens connected to our account. I don’t know of such an API, why there would be one or why this would happen so this explanation seems unlikely.

2. Something similar to 1 is going on at the server side, within Twitter. Again, possible but very odd behaviour.

3. Something we’ve missed at our end is somehow getting these tokens to get remembered, jump across a machine boundary, and get picked up by the stream API client and used each time it reconnects.

We’ll do a more detailed review at our end and see what we can turn up, but still currently mystified as to where these user ids are coming from.

[andypiper]

we issue the client with our own token instead and throw away the original authtoken provided by Twitter.

That’s your login process, not the Twitter Auth side. I don’t see any way you could use a token you generated independently to access the API. I’ll leave you to dig in but I don’t see a way this could be an issue on Twitter’s side right now.

[system]

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.