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…
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.
Something similar to 1 is going on at the server side, within Twitter. Again, possible but very odd behaviour.
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.