Twitter timeline import loops

Twitter timeline import loops

Issue ID:2268
Issue Category:bug
Component:uncategorized
Priority:normal
Status:fixed
Assigned:zach
Version:0.9
Milestone:0.9
Keywords:twitterbridge

(I did a full re-install to reproduce so this is from a clean instance)

Admin:

* additional preferences to the default config.php:
{{{
addPlugin('TwitterBridge');
$config['admin']['panels'][] = 'twitter';
}}}
* create App on twitter as described in plugins/TwitterBridge/README
* set parameters on Admin->Twitter with twitter app data on the web interface
* startup daemons

User:

* connect to your Twitter account (Connections/Verbinden->Twitter "Connect to your Twitter account")
* preferences set on Connections/Verbinden->Twitter: "Import my friends timeline" only.
* Change to Home/Personal
* Wait for timeline tweets to be imported
* click Home/Personal again
* Dent something
* you will see your dent above the timeline tweets
* Wait some time (5 minutes or so)
* click Home/Personal again

EXPECTED:

(if no new tweets came in in the waiting time)

your dent is above the timeline tweets (as before)

(if tweets came in)

your dent is between the old an the new tweets

IS:

Only the timeline tweets can be seen, if you click pages back the timeline loops some times (worst case up to 50 or 60 times). The last loop contains your dent at the right position.

The same effect can be seen with twitter clients (seen with Choqok and Witter). You can see the effect only if you start the client some time after you post a dent (the clients are caching and then correlating the tweets/dents otherwise)

* post a dent with the web interface
* start client and you can see your post
* close client
* post another dent with the web interface
* wait some time (30 minutes or so)
* start the client and you do not see the post.

Legacy Data

This issue was migrated from another tracking system. The legacy data at time of import is provided below as a reference.

Ticket ID: 
2268
Reported by: 
cy8aer
Owner: 
zcopley
Status: 
assigned
Type: 
bug
Component: 
uncategorized
Priority: 
3
Version: 
0.9
Milestone: 
0.9

Updates

#1

Per the README, you can prevent the looping by setting a config variable so the system knows which app name to avoid re-reading:

Additionally, you will want to set the integration source variable,
which will keep notices posted to Twitter via StatusNet from looping
back.  You can do this in the Twitter bridge administration panel, or
via config.php. The integration source should be set to the name of your
application _exactly_ as you specified it on the settings page for your
StatusNet application on Twitter, e.g.:

    $config['integration']['source'] = 'YourApp';

Seems like we ought to be able to sidestep that in some way... but if the source name is always set in the OAuth app config, we may not actually have the info otherwise. :(

Definitely this should be made easier to configure though, and should probably be settable via the admin panels.

#2

Actually come to think of it, under the newest system where we track the relationships between things that come in/out over the bridge we should be able to confirm we've already seen a message and avoid importing it.

Looks like currently the tracking in notice_to_status will indeed keep us from re-saving the same notice, but it may still re-add to peoples' inboxes...

For your own outgoing messages or other people subscribing to both you locally and your Twitter self, the inbox checks should avoid a double-addition and all should look well. But folks who are subbed to the Twitter side and not this end will, I think, get it added to their inboxes but *not* receive any delivery notifications.

May need some more restructuring on the import to make that work totally smoothly.

#3

Status:active» fixed

Did a quick local test, seems to work well enough. The double-add if it happens is harmless as we have protection against that now.

Login or Register to modify this issue, or to receive updates by email.

You can also subscribe to the RSS feed for updates to this issue.