Nursing RSS Graffiti

This is a partial screenshot from the new “Application...

Sat, 12 Jun 2020 14:49:06 +0200

This is a partial screenshot from the new “Application Settings” tab in RSS Graffiti. Each user will be able to associate multiple twitter and bit.ly accounts with their Facebook account and then designate these accounts for use in processing different feeds or targets. These features will be included in the upcoming RSS Graffiti version 1.9.0 Beta.

Bit.ly links

Fri, 11 Jun 2020 22:56:00 +0200

Many users are often puzzled by the way RSS Graffiti uses Bit.ly links. So questions keep coming in about this and that, on Bit.ly links in RSS Graffiti. It’s only reasonable because the feature is neither fully, nor properly implemented in RSS Graffiti yet.

So here is what is currently going on with bit.ly links on RSS Graffiti and what is about to change in the upcoming RSS Graffiti version 1.9.0 Beta.

Current problems:

Issue #1: RSS Graffiti does not use bit.ly to shorten all links posted on Facebook. That is bad and it is about to change in the upcoming version 1.9.0 Beta. It does not use bit.ly to shorten all URLs because that was not our initial intention. We introduced bit.ly in order to be able to add a short URL on Status Updates. We did that, but then neglected to expand the use of bit.ly to shorten all URLs before posting the on Facebook.
Issue #2: RSS Graffiti currently tries to create short URLs through bit.ly even if you did not specify a bit.ly account to use for connecting to bit.ly. It just uses silently its own bit.ly account. At the beginning this was nice because anybody would get a short URL on their Status Updates regardless of whether they had a bit.ly account or not. But now that RSS Graffiti has grown it turns out to be bad because bit.ly will not always respond to our requests for shortening a URL depending on the volume of requests we have been doing with the same account.
Issue #3: Nobody complained about this but it is a serious design issue. A Bit.ly account is currently a property of a target (Facebook Fan Page, Profile or Group). This is not as flexible as we would like it to be especially if someone administers a lot of Fan Pages or Groups.

What is changing in the next version:

RSS Graffiti version 1.9.0 Beta is about to be released and it does address all the above issues.

Bit.ly accounts will be now associated with the user instead of the target. Each user will be able to specify multiple bit.ly accounts. The user will then be able to assign the same account to multiple targets and multiple feeds. So different feeds in the same target will be able to use different bit.ly accounts. These settings will be cascading from the user to the target and then on to the feed. So if a feed does not specify a bit.ly account for using in shortening URLs, then the one specified on the target will be used. Likewise, if a target does not specify a default bit.ly account then the default account of the user will be used. This system also takes care of Fan Pages with multiple administrators and makes it clear to each admin which account is being used and who configured it. At the same time the same system will be dead simple for people that don’t really need this complexity and only have one bit.ly account and a Facebook Profile. If you add just one account then that account is going to be the default for everything.
RSS Graffiti version 1.9.0 Beta will also use your bit.ly account to shorten all URLs it posts to Facebook. This will help you keep track on clicks through bit.ly. Later on we plan to use bit.ly’s API to bring some of those statistics inside RSS Graffiti for making your life even easier.

We will give you more details on all these as soon as we are ready for the release.

Sporadic problems with Twitter feeds

Fri, 28 May 2020 12:26:00 +0200

As RSS Graffiti user base grows, we recently started to run into quota problems with Twitter again. This means that some of you already see sporadic failures in publishing your Tweets to Facebook followed by a message from RSS Graffiti that says that a valid feed could not be found in your Twitter feed URL.

This is caused by the fact that RSS Graffiti (although white-listed by Twitter) has a limit of 20.000 requests per hour. Sometimes this limit is exceeded and the problem mentioned above occurres.

There is no need to worry too much about this issue though, as we have already implemented and will release in the coming days a new feature in RSS Graffiti that will eliminate this issue. More specifically RSS Graffiti, starting from its next version, will allow you to connect your own Twitter account and it will then be able to use it to connect with Twitter for you.

This means that instead of using RSS Graffiti’s own Twitter account for getting everyone’s tweets from Twitter, we will be able to use the account of each user for retrieving their own tweets. Although each user has a much lower Twitter quota than RSS Graffiti, their own quota should be enough for the needs of each user. On top of that, we can always automatically fall-back to our own default account in case someone’s quota is temporarily exceeded.

You will also be able to specify multiple twitter accounts and use different accounts for different feeds, or even specify default accounts for use in different pages. These are going to be quite useful for users that manage a lot of Fan Pages and Groups.

So there you have it! Hang on for a few more days! Do also stay tuned with us, as we have lots of more interesting features build specifically for Twitter coming in our next release(s).

The troublesome 341 Facebook errors.

Sun, 28 Mar 2021 14:17:00 +0200

In the past days we have been experiencing serious issues in posting stories to Facebook. Many attempts to post a story to Facebook result in the following Facebook error (and fail):

Error Number: 341
Error Identifier: API_EC_EDIT_FEED_TOO_MANY_USER_ACTION_CALLS
Error Description: Feed action request limit reached

This roughly seems to mean that we done too many “user action calls” and thus reached the limit of calls Facebook imposes.

This sounds like bad news since we did not increase the number of calls we make before the error started appearing, which means that this limit (if it exists) is a new limit that was imposed by Facebook (or an old limit they just started enforcing).

The good news (unfortunately they don’t seem to get better than this) is that we don’t really know what is going on. Which means we don’t really know yet if this is a bug or a feature.

We, in RSS Graffiti, still regard this as a Facebook bug. To see this as a feature we need some proof that this limit exists and is purposefuly enforced by Facebook. We need some documentation on this. And so far we found no documentation for this supposed limit what so ever.

There is a related bug (#7624) filed in Facebook’s bug tracker for this issue. You can find it here: http://bugs.developers.facebook.com/show_bug.cgi?id=7624

It is obvious that this issue is not bothering just us in RSS Graffiti. Facebook bug #7624 has at the time I’m writing this 621 votes and a status of “NEW”. Which means that basically it was filed and confirmed by popular vote, but Facebook has not assigned it yet to anyone for fixing it. So the issue still remains to attract Facebook’s attention to this issue. It’s been already over 3-4 days that this issue is affecting us and I’m not very optimistic on how this will turn out.

Now what can we do about this?

Here is our list of things to do about this:

Attract Facebook’s attention so that they either fix the bug or provide us with some documentation on this limits rules and how to live with it.
Prepare for the worse.

To attract Facebook’s attention we must bring the votes for this bug to over 1200. If you have a look at http://developers.facebook.com/live_status.php you will see in the bottom right section that the top bug in their list has over 4.000 votes and the last of the top bugs has over 1.000 votes. If we don’t get this bug in that list I personally doubt that it is going to get any attention anytime soon. If you are a developer and feel affected by this issue then please move all the votes you can spare to this bug.

How do we prepare for the worse?

For the past weeks we have been hard at work to prepare our next release. In there there are quite a few new and interesting things for everyone, some of which will help us out in minimizing the effects of this bug. At the moment we are not ready to release everything yet but we are investigating the possibilities of releasing some of the stuff we have prepared and making some adjustments to allow us to live with this issue until it is cleared. We plan to do this next release on Tuesday (March 30th, 2010). After that, we will consider how we deal with this depending on any relevant information we can get from Facebook.

How does this bug affect RSS Graffiti at the moment?

The obvious result to everyone is that nothing is posted on your wall after the limit is hit for your account. The limit for RSS Graffiti seems to be currently at 30 posts per user per day. (At least that’s what Facebook says in RSS Graffiti’s dashboard about the request limit, but it is still unclear if this limit is the same as the one we are hitting).

Apart from the obvious though there are even more issues caused in RSS Graffiti as a result of this bug. Since there are many users that have a lot of feeds in their pages a long queue of unpublished stories is being built up for them by the minute. As a result the background processes that work on those feeds hit take a much longer time to finish due to mechanisms we have for retrying and logging errors. This in turn degrades the performance of the whole system and the 5 minute cycle we used to enjoy cannot be maintained all the time. We often see cycles of 20 or 30 minutes when lots of feeds with a huge backlog are being processed.

To cope with this we have a number of new features that we were planning for our next release in place.

Our next release is going to improve logging and decrease the time spent while logging all this huge number of errors. There is a lot more we have on the works about logging but we can release what we already have in place to ease this pain as soon as possible.

Another thing that is coming up with our next release is a new communication system between RSS Graffiti and it’s users, which will allow us to simply disable all feeds that have permanent errors and send a message to their admins. This will pause a large number of feeds that fail due to permissions errors which are still being processed now despite the fact that they won’t work unless some action is take by their administrator. Don’t be alarmed because we are not going to disable all feeds that have any kind of error (like for instance this 341 error); we just going to pause the feeds that definitely require some action from the user in order to start working again. This will significantly unload the burden of processing cycles and help bring them back to out usual standards.

There is yet another thing that will help in this situation and is included in our next release: limits! RSS Graffiti will now give you the ability to specify the maximum number of items to be posted in every cycle. This was planned as a feature anyway, but it will help you control the effects of this issue too until it gets fixed.

At the same time we are planning for ways to handle the new Facebook request limit if it turns out to be real. We already had some things in mind (like aggregated stories) but we are trying to figure out in which ways we can give you control of the usage you are making on your API limits. Twitter has a nice system in place for their API limits. Facebook unfortunately still lacks this fine grained control but we do believe that if this request limit is real then they will probably provide developers with ways of checking the remaining number of requests per user and control the distribution of the remaining usage at any given moment.

We will keep monitoring this issue and will keep trying to find ways to minimize it’s impact (or even make the best of it). We hope to get Facebook involved with this serious issue very soon and get this out of our way fast because there is all sorts of exciting things we have been working on and want to put forward in RSS Graffiti. We hope and work for the best.

CSS Caching Issues - IE ONLY

Wed, 03 Feb 2021 03:54:00 +0100

UPDATE | Feb 9, 2010:

This issue has been resolved in RSS Graffiti version 1.8.6 Beta.

We just noticed that an old bug from Facebook, causing problems with application CSS loading, is still alive, especially the last few days with the intermittent performance issues of the facebook API platform.

You might experience a broken layout, in the Feed Preview mode in particular - if you are using IE as your browser.

More on the Platform perfromance issues you can find here…

More on the specific bug you can find here…

We hope this issue will get fixed soon, and ask for your patience in the meanwhile.

Problems with feeds from Yahoo! Pipes

Mon, 01 Feb 2021 14:44:00 +0100

The past few days our users that have Yahoo! Pipes feeds added to their Facebook Profiles and Fan Pages, started reporting that their Yahoo! Pipes feeds suddenly “stopped working”. Their feeds stopped posting for a few hours then some of them posted some entries and then paused again for a few hours and so on.

Looking into this, we discovered something we probably should have thought about earlier: Yahoo! has a hard rate limit imposed on Pipes. This means that Yahoo! only accepts to execute a Pipe just a given number of times per hour. If that limit is exceeded then the Pipe is blocked for an hour; and so on.

The limits of Yahoo! Pipes are listed in their FAQ and seem to be as follows:

200 runs in 10 minutes for a given Pipe.
200 runs in 10 minutes for any Pipe from a given IP address.

Limit #1 is not a problem because RSS Graffiti runs each Pipe roughly every 4 minutes. So we never hit the limit #1. But limit #2 is indeed a problem because RSS Graffiti runs much more than 200 Pipes every 4 minutes. So since all runs come from the IP of RSS Graffiti’s server, the limit is exceeded and Yahoo! stops running any Pipe for RSS Graffiti for an hour after the limit is hit.

Before version 1.8.5 Beta, feed processing was not so often (every pipe was run once in every 30-40 minutes), so we did not face this problem. But now that we are able to make such frequent updates, we need to find other ways to overcome these limits.

Here are some workarounds we already have in the works:

First of all we already sent a request to Yahoo! for whitelisting RSS Graffiti’s server IP addresses so that the limit is raised to a more reasonable lever for our needs.

Another thing we are preparing for release ASAP is “per feed scheduling”. This will allow our users to set the number of minutes between updates to each feed. This way, users that really need Yahoo! Pipes will be able set their Yahoo! Pipes feeds to update less often than the rest of their feeds, effectively avoiding to hit the Yahoo! Limits.

We also noticed that most of our users that bring Yahoo! Pipes feeds to Facebook, actually do it to bring in their twitter feeds, after trimming their twitter usernames from the feed entries by using a Pipe. So we are already preparing a solution for those users: the next version of RSS Graffiti is going to trim the twitter username automatically from twitter feeds so there is not going to be a need for these users to turn to Yahoo! Pipes to do the trimming.

We will keep you posted on this. Our efforts will concentrate on having these alternatives available for you tomorrow.

Sporadic Publishing Failures

Thu, 28 Jan 2021 23:38:00 +0100

The last few days we have been receiving reports from some users that some of the items in their feeds do not show up on their wall although they are reported as published from RSS Graffiti.

We have been investigating this issue since yesterday and we managed to identify the reason this was happening. A Facebook API call (namely streamPublish) returns an unexpected response which was tricking our processing engine in thinking that the item was published when in fact we did not get a valid answer from Facebook and the fate of the published story could not be safely determined.

The Facebook API call in question is supposed to return the ID of the posted story or throw an exception if something went wrong and posting has failed. Since we do not need the ID of the posted story, we used to ignore it and unless an exception was thrown we assumed that the story has been published.

For the past few days this is not the case anymore. StreamPublish can return an invalid (empty) ID for the published story. This behavior is not documented and is probably a bug since it carries no information on what happened to the story that has been posted.

Today we altered the way we handle this call and we now examine the ID of the posted story as returned by Facebook. If it is empty (invalid) we assume that we hit this bug again and that we will have to retry the operation. To avoid changing the posting workflow in the feed processing engine of RSS Graffiti we decided not to retry posting immediately but rather to leave it for the next time the feed is processed. So what we actually do is interrupt the posting of the target (wall) that encountered the problem and move on to the next target. The target that was interrupted will be processed again in a few minutes and posting will continue from the point it stopped last time.

There are pros and cons in this approach and we are really not sure what is the best thing to do.

The two scenarios (solutions) of handling this situation are:

Ignore the story that failed and move on to the next story.
Interrupt processing and retry posting this story in the next cycle.

Solution 1 has the advantage that all the feeds that don’t hit this bug will be posted as soon as possible. The disadvantage is that the story that failed in the first effort will never make it to your wall if any newer stories are published successfully right after it on the same target.

Solution 2 has the advantage of having another chance to get all your stories on your wall in the right order but the disadvantage of a longer delay.

Of course there are more possible solutions to this problem but they fall out of the scope of a workaround. We don’t really need to start implementing any long term solutions since this issue is caused by a Facebook bug (rather than a feature). So as soon as Facebook fixes this things should go back to normal and the fix we are using now will stay in place just in case.

While this issue was being investigated today Facebook was reporting in it Platform Live Status that it is facing API Issues. The problem we are investigating might be related to the problems reported by Facebook but there is no way of confirming this for the moment.

We will keep monitoring and working on this issue until it does not affect us anymore.

Fan Page authorization possible again: Facebook bug #7243 fixed.

Wed, 28 Oct 2020 16:36:39 +0100

As of early today Facebook bug #7243 which was preventing some users from granting special permissions to enable publishing in their Fan Pages has been resolved so everything is back to normal now. This was the 2nd time we were affected from a Facebook bug in the special permissions dialog and hopefully it will be the last one too.

RSS Graffiti live again on the new servers!

Mon, 19 Oct 2020 02:34:06 +0200

Things are pretty much back to normal after a very long and difficult day of urgently migrating to a new hosting provider.

RSS Graffiti now runs on the cloud and although we did not iron out all the edges yet, we are pretty confident that the flexibility we now have in terms of infrastructure will allow us to maintain a good service for the coming months and accommodate for the increasing demand of the application.

We will keep monitoring the new deployment and will try to optimize processing of your feeds during the rest of this week.

Big thank-yous to all of you for baring with us today!

Moving to new servers

Sun, 18 Oct 2020 22:10:08 +0200

We are in the process of moving RSS Graffiti to new servers on the the cloud. The process has already taken several hours today and there is still lots of work to be done; but we are getting there.

Although we planed to make this transition later this week an ugly surprise from our current hosting provider forced us into the decision to move on with the planned migration right away.

The new server is up and running on the cloud and RSS Graffiti is being tested in the new environment. We are still in the process of moving over our huge database. We plan to start the background processes as soon as possible to restart processing your feeds and a short while after that to open the user interface of the application for accepting new sign-ups and modifications from existing users.

Thanks for your patience today with us. We will let you know as soon as this process is over.

Version 1.6.0 Beta up running

Fri, 16 Oct 2020 14:21:13 +0200

Early on Friday, Oct 16, we deployed version 1.6.0 Beta which seems to run quite well so far. There is a heavy load on our server lately but it has not caused any serious problems so far. All feeds are being updated every 5 to 9 minutes. We are already in the process of preparing the transition to a new hosting environment that will provide more capacity to RSS Graffiti for processing your feeds.

Up and running

Sun, 30 Aug 2020 15:37:42 +0200

RSS Graffiti version 1.3.1 Beta is currently running in production. Everything seems to be just fine for all users.

We are working to improve our monitoring tools to make sure no updates are ever missed for anyone. Some of these tools might be released for our users too so that they know first hand if any problems are encountered with any of their feeds.

Meanwhile RSS Graffiti continues to grow steadily in user-base. We have been almost doubling our users every day since launch. A big thanks to everyone for your support! :-)

Back to normal

Wed, 19 Aug 2020 01:50:55 +0200

Updates have been enabled again after deploying a patch for the bug mentioned in the previous post. Version 1.2.0.200 Beta is now live in the production server.

Updates paused for a while

Tue, 18 Aug 2020 17:56:59 +0200

We have currently paused the updates to your walls until we deploy a fix to a bug that caused many feeds to repeatedly post some updates. The patch will be deployed later tonight after we have enough time to test it.

Up and running

Tue, 18 Aug 2020 14:49:56 +0200

The issues on our server have been resolved. The Facebook Application is up and running again.

Server down

Tue, 18 Aug 2020 14:10:29 +0200

Our hosting provider is currently experiencing some problem and as a result the Facebook Application is currently unavailable.