Warnings in the activity_process_queue cron task

[Aaron Wells]

To replicate:

1. Do a clean install of Mahara 1.8dev (from master)
2. After installation is complete, run the cron job.

You see a bunch of warning messages from the activity_process_queue task:

[INF] ab (lib/cron.php:153) Running core cron activity_process_queue
[DBG] ab (lib/activity.php:224) profile_url called with no user id
[WAR] ab (lib/errors.php:749) Failed to get a recordset: postgres7 error: [-2: ERROR: syntax error at or near "LIMIT"
[WAR] ab (lib/errors.php:749) LINE 1: SELECT * FROM "group" WHERE "id" = ? LIMIT 2
[WAR] ab (lib/errors.php:749) ^] in adodb_throw(SELECT * FROM "group" WHERE "id" = ? LIMIT 2, )
[WAR] ab (lib/errors.php:749) Command was: SELECT * FROM "group" WHERE "id" = ?
Call stack (most recent first):
  * log_message("Failed to get a recordset: postgres7 error: [-2: E...", 8, true, true) at /home/aaronw/www/mahara/htdocs/lib/errors.php:109
  * log_warn("Failed to get a recordset: postgres7 error: [-2: E...") at /home/aaronw/www/mahara/htdocs/lib/errors.php:749
  * SQLException->__construct("Failed to get a recordset: postgres7 error: [-2: E...") at /home/aaronw/www/mahara/htdocs/lib/dml.php:492
  * get_recordset_sql("SELECT * FROM "group" WHERE "id" = ? ", array(size 0), 0, 2) at /home/aaronw/www/mahara/htdocs/lib/dml.php:333
  * get_record_sql("SELECT * FROM "group" WHERE "id" = ? ", array(size 0)) at /home/aaronw/www/mahara/htdocs/lib/dml.php:310
  * get_record("group", "id", null) at /home/aaronw/www/mahara/htdocs/lib/view.php:775
  * View->get_group_object() at /home/aaronw/www/mahara/htdocs/lib/view.php:4429
  * View->get_url(false) at /home/aaronw/www/mahara/htdocs/lib/activity.php:960
  * ActivityTypeViewaccess->__construct(object(stdClass), true) at /home/aaronw/www/mahara/htdocs/lib/activity.php:77
  * handle_activity("4", object(stdClass), true) at /home/aaronw/www/mahara/htdocs/lib/activity.php:219
  * activity_process_queue() at /home/aaronw/www/mahara/htdocs/lib/cron.php:158

[DBG] ab (lib/activity.php:224) Failed to get a recordset: postgres7 error: [-2: ERROR: syntax error at or near "LIMIT"
[DBG] ab (lib/activity.php:224) LINE 1: SELECT * FROM "group" WHERE "id" = ? LIMIT 2
[DBG] ab (lib/activity.php:224) ^] in adodb_throw(SELECT * FROM "group" WHERE "id" = ? LIMIT 2, )
[DBG] ab (lib/activity.php:224) Command was: SELECT * FROM "group" WHERE "id" = ?

[Aaron Wells (u-aaronw)]

It's a regression, because this doesn't happen with a clean install of 1.7. On the other hand, it's just a warning, not an error, so it doesn't seem to kill your cron job, just throw some junk into your log.

[Aaron Wells (u-aaronw)]

Specifically, you get this warning whenever there is any content in the activity_queue table. If it's empty, then activity_process_queue() doesn't throw a warning.

[Aaron Wells (u-aaronw)]

Using git bisect, it looks like the problem is caused by something added in the Pagemaker mega-change:

8b34dc82d4f25e8fec7f97658e5a53789dce8058 is the first bad commit
commit 8b34dc82d4f25e8fec7f97658e5a53789dce8058
Author: Robert Lyon <email address hidden>
Date: Mon Aug 5 09:45:29 2013 +1200

    Merging flexible layouts + artefact chooser panel + new UI changes

    - Bugs #1201258, #1181010, #1199563

    As these are all integrated together it is easier to test them as
    one patchset.

    Change-Id: I5ce68a4ea2de1de8b9deeb7d95380fcdcae095a0
    Signed-off-by: Robert Lyon <email address hidden>

[Aaron Wells (u-aaronw)]

Hm, ultimately this is happening because one of the changes in the code was to use the proper API functions for creating a view and changing its access (View::create() and $view->set_access()) rather than inserting directly into the database, when creating the Group Homepage template page. This causes a "viewaccess" notification to get sent to the root user.

And something in the handling of that viewaccess notification, is what causes this warning. Specifically, it looks like the problem is that the Group Homepage is a group of type "grouphomepage", but with NULL for its group column. That causes problems in the code that tries to fetch its group.

Additionally (and separately), there's that earlier notice, "[DBG] ab (lib/activity.php:224) profile_url called with no user id". THAT happens while it's trying to process the "Profile Page" template which belongs to the root user, and THAT has been present since 1.7 stable, so it is not a regression.

[Aaron Wells (u-aaronw)]

I figured the best thing to do is make the code that tries to generate the group homepage's URL be more robust for if the page has no group id. A more invasive alternative would have been to change the set_access() method so that you can tell it not to send out notifications, but it seemed like a less elegant solution to add a parameter to the method to turn off notifications when we're only ever likely to use it one time, during installation.

https://reviews.mahara.org/2468

[Mahara Bot (dev-mahara)]

Reviewed: https://reviews.mahara.org/2468
Committed: http://gitorious.org/mahara/mahara/commit/7e6a6f56b34fe1e883db99b06c1a2c8efee153fb
Submitter: Robert Lyon (<email address hidden>)
Branch: master

commit 7e6a6f56b34fe1e883db99b06c1a2c8efee153fb
Author: Aaron Wells <email address hidden>
Date: Tue Sep 3 15:14:06 2013 +1200

Fail more gracefully when a grouphomepage View doesn't have a group ID

Bug1220028: There is 1 grouphomepage in a standard Mahara which has no
group ID: The grouphomepage template page. And during installation, we
try to send out notifications about its creation. This prevents a warning
message coming up due to those notifications.

Change-Id: I32da82ffd15ca6902bdcf744fcc945e8735df7b8