Must resave settings to enable automatic item import via cron

Yes, I've had the same problem. If an activity stream causes the cron run to "hang" the stream seams to be ignored until it is saved again.

Same problem here. Any idea's on how to automate the resaving of all my users settings to fix this problem?

I don't think a fix is currently available. You just got to re-save once in awhile.

From a comment to #310564: Activity Stream not updating...

I think this is an issue of Drupal disabling Activity Stream's cron when one of the sub modules takes a long time to fetch it's feed. Saving the feed settings again causes Drupal to re-enable cron.

The solution here is to figure out a way to set a timeout or detect that a sub module is slow and force Drupal to keep the cron in place. Handle these errors inside the module instead of allowing Drupal to do it for us.

There isn't a way to fix this, per se. Drupal is behaving in the way it was designed. Fetching items from a third party API can be slow and trigger Drupal to kill the module's cron job.

You don't need to go in and re-save all the user's information. Just re-saving once for one user should do it.

@alesky:

Are you sure that if you update just one user it causes all users activity streams to be fixed? The reason i say this is because sometimes certain people's activity streams (or certain services) will stop working while others will still be working. Sometimes it will just be my facebook status messages that stop while my delicious bookmarks keep feeding.

If you do just have to resave one persons settings... any tips on how to setup a cron job or something to automatically do this?

Re-Saving one users activity settings does not always fix other users stalled feeds. I just did an experiment with it and in some cases it will jumpstart another users feed. But in my latest attempt it didn't restart a specific users feed and i had to go under that specific users activity stream and resave.

Is this problem stemming from my cheap vps hosting or what? (it did this locally on my xampp also)

In 2.x-dev, the module has support for Job Queue. If Job Queue is installed, updates are queued instead of pushed directly through cron. Using Job Queue should solve this issue.

Same problem here.
Any fix?

Please don't post the same issue multiple times. According to your post at #434220: stream update your issue is not the same as this one.

Automatically closed -- issue fixed for 2 weeks with no activity.

I've been working on this issue for a bit. I noticed it happening awhile back, but knew that saving the entries fixes it, so I ignored it for a bit. As it turns out, what is happening is the activitystream_accounts table is losing entries. I'm not sure why, and I'm even less certain how the edit page for activity stream is showing the entries to be able to save them back to this table, but I'm in the midst of hunting it down.

I've tracked the issue down.

In the activitystream_save_account function in activitystream.module the first thing the function does is check to see if the $params has anything in it with

if (count($params) == 0) {
return FALSE;
}

However, the keys are always populated in $params. So this never returns false. Unfortunately the next thing the function does is nuke the entries in the activitystream_accounts table. This happens whenever a user's account page is viewed, so that's why most of you have been experiencing this happening seemingly at random.

I haven't looked into what it will take to make sure that they keys don't exist in the $params array when it is empty, but here's a quick and dirty solution

At the very top of the function coment out the code above and add in this new code above it as so:

Great find!

With your code, empty parameters would not be saved. This means that if someone removes their twitter ID, it won't be deleted from the system.

The proper fix is to check during hook_user and only run the update operation if the category being saved is activitystream. Much like is done during the "form" operation already.

Fixed and in CVS for both the 2.x-dev and 1.0. New 1.x RC coming shortly.

Anyone want to port the fix to D5?

Automatically closed -- issue fixed for 2 weeks with no activity.