A ruleset is created containing rules to be executed at a specific time. This ruleset is scheduled by a reaction rule.
The trigger is when a new user is saved.
When a new user is saved the scheduled task is created and can be found in the rules_scheduler table. Now, executing Cron manually brings the following error message:
Fatal error: Call to a member function restoreBlocks() on a non-object in /var/www/drupal7/sites/all/modules/rules/rules_scheduler/rules_scheduler.module on line 62.
When Cron is executed before the task is scheduled it remains in the table (as it should be).
After its scheduled time it is deleted from the table.
Nevertheless, in both cases this problem occurs.
The task itself was not executed at all.
Drupal v7.14, Rules/Scheduler 7.x-2.1.

Files: 
CommentFileSizeAuthor
#7 rules_scheduler.txt4.32 KBlollipopp

Comments

lollipopp’s picture

I forgot to mention that PostGresql is used.

lollipopp’s picture

Version:7.x-2.1» 7.x-2.2
Priority:Normal» Major

This issue still remains with rules 7.x-2.2 and D7.15.
Some more details:
The data represented as JSon string is saved in the database for further processing but is neither deserialized nor unescaped using functions such as pg_unescape.
All of this applies for Postgresql only.
Furthermore, the value stored in the DB seems to be cut off due to an error when the DB table rules_scheduler was created. varying(64) does not seem to be enough for this field.
Please fix this matter as soon as possible.

nevos’s picture

do you mean that the scheduler doesn't perform it's task (whether the cron runs or not)?
If so -
I'm using postgres and hitting the same situation.

lollipopp’s picture

Yes, the scheduler is not performing its task. The task itself does not seem to be malformed, executing it manually shows the result expected.

lollipopp’s picture

By saying manually, I refer to the manual execution of the rule by clicking on execute.

mitchell’s picture

Title:Error in rules Scheduler module when task is processed» Error in rules Scheduler module when task is processed
Version:7.x-2.2» 7.x-2.x-dev
Status:Active» Postponed (maintainer needs more info)

This is a complete guess, but I think this is due to the data type being unknown to Entity API for rules_wrap_data(). Please provide more info about the data being processed or how track this error down.

lollipopp’s picture

StatusFileSize
new4.32 KB

This is the rule in its JSON representation:

{ "rules_afterregister" : {
    "LABEL" : "AfterRegister",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "rules", "rules_scheduler" ],
    "ON" : [ "user_insert" ],
    "IF" : [
      { "NOT user_has_role" : {
          "account" : [ "site:current-user" ],
          "roles" : { "value" : { "3" : "3" } }
        }
      }
    ],
    "DO" : [
      { "redirect" : { "url" : "registerinfo" } },
      { "user_add_role" : { "account" : [ "account" ], "roles" : { "value" : { "4" : "4" } } } },
      { "schedule" : {
          "component" : "rules_userrulesonregister",
          "date" : "+1 day",
          "identifier" : "Deletion task for new user login name [account:name] and UID [account:uid]",
          "param_uuser" : [ "account" ]
        }
      }
    ]
  }
}

The component referenced above should not be relevant. If required, I could post it, too.
When a user is inserted following can be found in the rules_scheduler table (dump, attached) where one of this rule has been scheduled.

mitchell’s picture

Please post the component.

lollipopp’s picture

This is the component:

{ "rules_userrulesonregister" : {
    "LABEL" : "UserRulesOnRegister",
    "PLUGIN" : "rule set",
    "REQUIRES" : [ "rules" ],
    "USES VARIABLES" : { "uuser" : { "label" : "UnvalidatedUser", "type" : "user" } },
    "RULES" : [
      { "RULE" : {
          "IF" : [
            { "NOT user_has_role" : { "account" : [ "uuser" ], "roles" : { "value" : { "3" : "3" } } } },
            { "AND" : [] },
            { "data_is_empty" : { "data" : [ "uuser:last-login" ] } },
            { "AND" : [] },
            { "data_is" : {
                "data" : [ "uuser:created" ],
                "op" : "\u003C",
                "value" : { "select" : "site:current-date", "date_offset" : { "value" : 300 } }
              }
            }
          ],
          "DO" : [ { "entity_delete" : { "data" : [ "uuser" ] } } ],
          "LABEL" : "DeleteNewUserNotValidated"
        }
      }
    ]
  }
}
nevos’s picture

I'm also still having this difficulty, and this may be (or not) related to postgress.
However, I get also this on the error log:
after "cron completed successfully" I get the following message:
Notice: unserialize(): Error at offset 23 of 26 bytes in rules_scheduler_run_task() (line 61 of .../rules/rules_scheduler/rules_scheduler.module), which I suspect is the reason for this error.

See similar issue in this thread: http://drupal.org/node/1615472

kcupid’s picture

Status:Postponed (maintainer needs more info)» Active

has this been resolved as it has been since June 2012 and the additional information requested has been provided. I too am getting this error even after I've cleared out all scheduled task

Attempting to re-run cron while it is already running. Call to a member function restoreBlocks() on a non-object (line 62 of /var/www/html/drupal/sites/all/modules/rules/rules_scheduler/rules_scheduler.module).

The deletes it self however it does not actually run(as the component I have setup send an email notification). I also notice that randomly after a few days or weeks it goes through. I'm using ultimate cron and i recently put on elysia however both are giving the error which makes me inclined to believe that it is an issue with rules_scheduler_tasks.

kcupid’s picture

Assigned:Unassigned» kcupid
Status:Active» Closed (fixed)

To anyone having this problem the solution for me was inserting a watchdog error in the rules scheduler module that printed out the array for $task. From that I was able to determine the component type giving me the error. After deleting the component giving the error all my old jobs came up.
If you are not into programming simply export all you components and delete them one by one until you find the offending component.

Placing as closed but feel free to open back. In my opinion the fault is not in scheduler but in a component that may have had an error in creation(although mine worked fine for a while before i got the error)

threewestwinds’s picture

Title:Error in rules Scheduler module when task is processed » Error in rules Scheduler module on PostgreSQL
Assigned:kcupid» Unassigned
Priority:Major» Normal
Status:Closed (fixed)» Active

This is not fixed - what you posted is a workaround, not a solution. Also, assigning an issue to yourself generally means you're working on a patch or otherwise attempting to solve the problem - it's to prevent duplication of effort rather than a claim of credit.

if a rules component has an error, then I'd expect the validity checker to notice. At the very least, we should be getting a helpful log message describing why the component in question failed.

Is more information still required than lollipopp's component? I could provide an export of my rule/component as well if it would help (I'm updaing content, scheduled based on a Date field - nothing complex enough that it should cause an error).

I haven't checked the code, but if I had to guess, I'd say that the problem is in serializing/unserializing an entity reference for rules_scheduler.

christoph’s picture

It looks like the RulesState object is getting truncated somehow. This is the 'data' value stored in the queue table. It ends up looking like this on unserialize (at rules_scheduler.module line 58 ($state->restoreBlocks() fails):

Array
(
[tid] => 5
[config] => rules_test
[date] => 1352963700
[state] => O:10:"RulesState":3:{s:7:"
[identifier] => unpublish387
)

This may happen in the job_scheduler module. Hopefully may find out a bit more.

christoph’s picture

Actually, it looks like the RulesState object isn't being correctly serialized in the first place (in rules_scheduler_action_schedule in rules_scheduler/rules_scheduler.rules.inc). It appears to be initiated fine, but when trying to serialize this object immediately after initiation I see the same result as above

O:10:"RulesState":3:{s:7:"

Can't see quite where that is happening. There was talk of a php bug where ArrayObject wasn't serializing (but that was related to having an Iterator in it), so not sure if that is the issue. This must be a very specific issue as otherwise more people should see it. Am on PHP v 5.3.2

-->Found on another site, so have created a new issue here: https://drupal.org/node/2012680

kcupid’s picture

threewinds..moderator or not you should get off your high horse..I didn't assign to me to claim credit. I only did it because I wasn't sure how to fill out the stupid form.

Secondly it is a valid fix. It fixed my problem as the issue was a corrupted component.I only posted it to help any one else having a problem(which it just so happens is the reason I am back here after having the problem again). Your attitude really isn't necessary and is problem the reason there is an exodus to WP from drupal

if a rules component has an error, then I'd expect the validity checker to notice. At the very least, we should be getting a helpful log message describing why the component in question failed.

Which is exactly what I did by putting in the watch dog as the information out of rules isn't sufficient to narrow down the error. Maybe the recommendation should be for whoever maintains the code to add a bit more information when this error is thrown

dixon_’s picture

For me it worked clearing the Rules cache (which I have a feeling is not cleared with other caches). Clearing that cache can be done at: /admin/config/workflow/rules/settings/advanced

paparoach’s picture

Issue summary:View changes

Working perfectly for me, hope this helps you.
This applies only to Postgresql users. After a task gets scheduled, if you look in the rules_scheduler table in the database, you will notice that the data column (of type text) has a partial serialized object. Php serialization represents empty data as a null byte (\0) and writing this data out as a string with the null byte in it will result in a truncated string when writing to the database. This led to the question of why is the data column defined as text and not blob (bytea). Bingo! Change your data column to bytea and everything will start working correctly. It doesn't matter that the schema in the rules_scheduler.install file says the data column should be text.
sql to change the data type:
ALTER TABLE rules_scheduler
ALTER COLUMN data TYPE bytea USING data::bytea;

Probably need to get rid of the bogus rows first.

HLopes’s picture

I'm using MySQL, converting the table to blob didn't fix it for me. Still have hanging cron tasks due to this.

It seems the serialization part is ok (i can see the blob values with the null bytes), but when unserializating the string gets truncated and throws a fatal error. At this point, i'm seriously considering @.

Any idea for a solution under MySQL?

Here's a slice of the problem...

O:10:"RulesState":3:{s:7:"\0*\0info";a:3: .....

This is using blob, using text it shows as

O:10:"RulesState":3:{s:7:"*info";a:3: .....

MatthijsB’s picture

Priority:Normal» Major

I can confirm that the ALTER TABLE... by paparoach in #18 works for me too, to fix the Scheduler issues with PostgreSQL. Paparoach is right in his observation that the 'data' column in the database only stored up to the first NULL character in the serialized data.
Like dixon_ said in #17, a thourough flush of old caches is neccessary, after altering the column type.

Can somebody please create a patch for this (and maybe a new stable release???)? (as there is no doubt that it is wrong to break serialized data at the first NULL occurence).
I checked other columns in the database that also store serialized data, and they are all of type bytea. This is the only column I found to be of type text (but I didn't check them all).

I upped the priority, because this issue breaks (most/all) rules scheduler functionality for PostgreSQL.

The issue described in for example #19 seems to be a different issue, as it mentions MySQL. I think it should better be investigated independently.

Drupal 7.34
Rules 7.x-2.8
PostgreSQL 9.1+134wheezy4 (Debian stable)