Loading Profile...
My TwitterFeed to identi.ca is looping over and over.
My TwitterFeed to identi.ca is looping over and over.
I'm feeding @sonicnet_status (http://twitter.com/statuses/user_time...) to http://identi.ca/sonicnet and it just keeps repeating the second to last update.
I've turned the feed off for now, but I would like to turn it back if it wouldn't repeat it self like this.
I'm feeding @sonicnet_status (http://twitter.com/statuses/user_time...) to http://identi.ca/sonicnet and it just keeps repeating the second to last update.
I've turned the feed off for now, but I would like to turn it back if it wouldn't repeat it self like this.
I’m confused
5
people have this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
-
Inappropriate?I've taken a closer look, and this looks slightly odd:
- our "last posted" timestamp, which holds the pubDate of the last item that was posted to identica from your feed, says "2009-07-17 01:22:11"
- this date matches the "CLEC DSL Card Replacement" post, however that post isn't the last one that was posted to identica
- so for some reason twitterfeed managed to update your identica account, but didn't update the "last posted" value, which would explain why it tries to repost the more recent items
- the only way this can happen is that we don't receive back a "200 OK" HTTP status from identica. Looking at the last status in the feed, it says "identi.ca responded: 500 read timeout". What I am thinking, although I can't be sure, is that perhaps we managed to update your identica status despite identica returning a non-200/OK status. In other words, twitterfeed assumes that the post hasn't made it through because identica returned an error status, but the post actually made it through despite the error status. If that's the case, then it would be an issue at the identica end, but as I said, it's hard to be sure. But because we didn't receive an OK, we don't update the "last posted" value, and keep trying to post the item again the next time we process the feed. -
Inappropriate?I'll turn the feed back on and see what happens; the few times I went to identi.ca I was seeing 500 return code as well; maybe they were doing some maintenance; thank you for the prompt and concise response, it is very much appreciated.
I’m thankful
4 Comments
Add a comment
This solves the problem
-
Turning the feed back on resulted in the same behaviour : repeating that one message over and over. Any other ideas? -
That's very strange - in the status for that feed I'm still getting "identi.ca responded: 500 read timeout", and the "last posted" value is still as above, the 17th July, which is why twitterfeed keeps re-trying to post the same item.
I'm not sure what's the easiest way to verify this, but am almost convinced that the post to identi.ca goes through, but indenti.ca returns non-200/OK status message anyway, which makes twitterfeed think that it hasn't gone through. -
That makes sense Mario, unfortunately that puts the ball in Twitterfeed's court to fix the bug.
I can try deleting and re-adding the feed if you think that would help.
Thanks again for your prompt and knowledgeable replies. -
Well, actually if my theory is correct (which I don't know yet), then the bug wouldn't be on twitterfeed's side. If we don't get back a HTTP 200/OK status from the service we are posting to, then this means something went wrong, so we need to re-try this post. If we didn't do this, we would potentially lose lots of posts. The bug in that case would be that identi.ca sent back an incorrect HTTP status (i.e. if the post was sucessful, then it needs to send back a HTTP 200/OK, not some error status).
I'll keep checking this though, as it's theory at the moment. -
Inappropriate?The effect was seen by me multiple times.
@evan mentioned a 'server queue' problem which lets dents slip through BUT sends back an error to the client.
I am also seeing the same problem in #Twhirl from time to time.
I’m anxious
-
Inappropriate?Hey guys, we're looking into this. It may be load related and we may need to beef up our transaction. However, just a note: we do return 500 if the user posts the same thing too quickly to his/her notice stream (flood protection).4 Comments Add a comment
This solves the problem
-
Zach, thanks for your answer. Pls. check out the related issue 'Group admin issue: Manage bots posting to group' on trac: http://laconi.ca/trac/ticket/1692
An identification of bots and an optional following specific handling of single bots would be an enhancement for our not so ideal world.
In an ideal world everything would work perfectly smooth :) -
Thanks Zach - returning 500 is ok, the real problem is returning a 500 *and* posting the update. If you return 500 for flood protection and reject the update, then twitterfeed will try again, so that's ok. The real problem is if you return a 500 but still post the update, as this will make twitterfeed re-post the same item.
-
I sent Zach a direct tweet asking if there was any update.
-
Zach replied back with : "Sorry, nothing yet on the looping prob. Fix isn't trivial unfortunately."
EMPLOYEE
