Error or Timeout on PHP Scheduled Task Pointing to Certain Lists

[rackem]

Looks like there is a bug with the PHP Scheduled Task. I have two tasks that I had created a while ago that were working fine until relatively recently (~ 1 month). Then I started having problems.

One task started generating a PHP timeout error whenever I ran it. The task completed just fine, it just ran until it timed out and then I got an error.

The other task did not complete and gave me a mySQL 1064 error related to the list the task was pointing to in the settings.

I was pulling my hair out trying to figure out what could be going on. Both of these are pointed to a script file but I tried copying the code into the code box - that didn't work. Now both of these tasks I run manually as needed. So they aren't really tied to the list they are pointing to. Out of curiosity, I switched the list the tasks pointed to in the settings to a very simple list. Now both tasks work properly again!

So it perhaps there is an element in these lists that the PHP Scheduled Task conflicted with that prevented them from running properly.

Here is the mySQL error in case it is helpful for troubleshooting:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISTINCT `mps_players`.`id` AS __pk_val0 FROM `mps_players` FROM `mps_players` L' at line 43 SQL=SELECT DISTINCT `mps_players`.`id` AS `mps_players___id`, `mps_players`.`id` AS `mps_players___id_raw`, `mps_players`.`date_time` AS `mps_players___date_time`, `mps_players`.`date_time` AS `mps_players___date_time_raw`, `mps_players`.`first_name` AS `mps_players___first_name`, `mps_players`.`first_name` AS `mps_players___first_name_raw`, `mps_players`.`first_plus_nickname` AS `mps_players___first_plus_nickname`, `mps_players`.`first_plus_nickname` AS `mps_players___first_plus_nickname_raw`, `mps_players`.`last_name` AS `mps_players___last_name`, `mps_players`.`last_name` AS `mps_players___last_name_raw`, `mps_players`.`nickname` AS `mps_players___nickname`, `mps_players`.`nickname` AS `mps_players___nickname_raw`, `mps_players`.`sex` AS `mps_players___sex`, `mps_players`.`sex` AS `mps_players___sex_raw`, `mps_players`.`notes` AS `mps_players___notes`, `mps_players`.`notes` AS `mps_players___notes_raw`, `mps_players`.`backup_first_name` AS `mps_players___backup_first_name`, `mps_players`.`backup_first_name` AS `mps_players___backup_first_name_raw`, `mps_players`.`backup_last_name` AS `mps_players___backup_last_name`, `mps_players`.`backup_last_name` AS `mps_players___backup_last_name_raw`, `mps_players`.`backup_nickname` AS `mps_players___backup_nickname`, `mps_players`.`backup_nickname` AS `mps_players___backup_nickname_raw`, `mps_players`.`backup_sex` AS `mps_players___backup_sex`, `mps_players`.`backup_sex` AS `mps_players___backup_sex_raw`, `mps_players`.`compare_backup` AS `mps_players___compare_backup`, `mps_players`.`compare_backup` AS `mps_players___compare_backup_raw`, `mps_players`.`active` AS `mps_players___active`, `mps_players`.`active` AS `mps_players___active_raw`, `mps_players`.`updated` AS `mps_players___updated`, `mps_players`.`updated` AS `mps_players___updated_raw`, `mps_players`.`edit_by` AS `mps_players___edit_by_raw`, `btxz_users`.`name` AS `mps_players___edit_by`, `mps_players`.`edited_when` AS `mps_players___edited_when`, `mps_players`.`edited_when` AS `mps_players___edited_when_raw`, `mps_players`.`admin_notes` AS `mps_players___admin_notes`, `mps_players`.`admin_notes` AS `mps_players___admin_notes_raw`, `mps_players`.`order` AS `mps_players___order`, `mps_players`.`order` AS `mps_players___order_raw`, `mps_players`.`owner` AS `mps_players___owner_raw`, `btxz_users_0`.`username` AS `mps_players___owner`, `mps_players`.`id` AS slug , `mps_players`.`id` AS `__pk_val` ,DISTINCT `mps_players`.`id` AS __pk_val0 FROM `mps_players` FROM `mps_players` LEFT JOIN `btxz_users` AS `btxz_users` ON `btxz_users`.`id` = `mps_players`.`edit_by` LEFT JOIN `btxz_users` AS `btxz_users_0` ON `btxz_users_0`.`id` = `mps_players`.`owner` LEFT JOIN `btxz_users` AS `btxz_users` ON `btxz_users`.`id` = `mps_players`.`edit_by` LEFT JOIN `btxz_users` AS `btxz_users_0` ON `btxz_users_0`.`id` = `mps_players`.`owner` ORDER BY `mps_players`.`id` DESC


The only "odd" thing about either of the original lists my task was pointing to was that I use a dbjoin element pointed to the J! users list. Like I said, this was all working fine for quite a while so not really sure what changed.

I can make a test site available if that will help with tracking down the problem.

 

[cheesegrits]

So are you only ever seeing problems with the mps_players list in that context, running a PHP scheduled task on them?

How recent is "recent" as far as github goes?

-- hugh

 

[rackem]

Sorry Hugh, I don't have a specific date. I guessed a month but perhaps it goes back as far as mid Jan. as I was having other issues at that time. Not sure if it is coincidence or if they are related? Both seemed to go back to problems with the mySQL query structure.
http://www.fabrikar.com/forums/inde...-member-function-order-on-a-non-object.37591/

I purchased a subscription and you had started looking into it before running into some unrelated hardware problems on your end. Then I did some pruning on my site which seems to have worked around that earlier problem - at this point, the site is basically functional. However, I don't think the root cause was ever identified and my php error log grows quickly. My subscription ran out and I've exhausted my troubleshooting ideas so I haven't been able to pursue it.

 

[rackem]

*friendly bump*

 

[troester]

...`btxz_users_0`.`username` AS `mps_players___owner`,
`mps_players`.`id` AS slug ,
`mps_players`.`id` AS `__pk_val` ,
DISTINCT `mps_players`.`id` AS __pk_val0
FROM `mps_players` FROM `mps_players`
LEFT JOIN `btxz_users` AS `btxz_users` ON `btxz_users`.`id` = `mps_players`.`edit_by`
LEFT JOIN `btxz_users` AS `btxz_users_0` ON `btxz_users_0`.`id` = `mps_players`.`owner`
LEFT JOIN `btxz_users` AS `btxz_users` ON `btxz_users`.`id` = `mps_players`.`edit_by`
LEFT JOIN `btxz_users` AS `btxz_users_0` ON `btxz_users_0`.`id` = `mps_players`.`owner`
ORDER BY `mps_players`.`id` DESC

There seem to be several things mixed up in this list. Can you check what is shown in your list joins?
Maybe some old (deleted) joins are still existing.

Scheduled task: if your code isn't depending on the list data I would use a dummy list with just one record.

 

[rackem]

Hi troester, thank you for the response.

This list does not have any list joins.

As far as join type elements, it has one user element (edit_by) and one database join element (owner). The owner element links to the J! user table and I use it to mark records in mps_players that are "owned" by particular users. Not every record has an owner. If the record has an owner, only they and admin can edit it.

It is interesting that both lists that illustrate the problem of this thread have this format. Is it a problem to have a user and a regular database join can be pointed at the user table? All of this was working for several months prior to all of these issues.

I agree this seems to be messed up. Why does query contain duplicate LEFT JOINs? Also, it appears some of the mySQL column names are incorrect, e.g. `__pk_val`, `btxz_users_0`. I tried opening and re-saving the list and elements these odd names are referring to but I still receive the error.

Scheduled task: if your code isn't depending on the list data I would use a dummy list with just one record.

Yes, that is what I have done as a workaround, thank you

 

[troester]

`__pk_val`, `btxz_users_0`

Those are correct (you'll need a table alias for the 2nd join on the same table) but the duplicate LEFT JOINs surely aren't and DISTINCT `mps_players`.`id` AS __pk_val0, too.

Did you delete/recreate edit_by/owner? Anything in trash?

 

[rackem]

Did you delete/recreate edit_by/owner? Anything in trash?

The trash is empty. I am not sure if you are asking whether I did or suggesting I should delete/recreate the edit_by and owner elements? I have not tried to do so.

 

[rackem]

This issue has reared up again. I added some new tasks at the beginning of the year pointing to the tables in question as these lists receive the most traffic on my site. Strangely enough, my setup was working without issue until at least the end of March. I went to run it this weekend and had problems again so I assume something changed recently in GitHub? My last update was 4/17.

If I point to the list I want, the process times out and it isn't clear why. I tried an alternate list and get the reported error. The task runs fine if it is pointed to some of my simple lists.

It isn't in my PHP code. I can recreate with a new PHP Scheduled task pointing to these lists with just the following:

$processed = 99;

I was looking again at the 1064 error message. Note the duplicate FROM portion, it seems this is where the error occurs. You'll note the same thing in the error I reported previously on the other list in question.

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISTINCT `mps_locations`.`id` AS __pk_val0 FROM `mps_locations` FROM `mps_locati' at line 35 SQL=SELECT DISTINCT `mps_locations`.`name` AS `mps_locations___name`, `mps_locations`.`name` AS `mps_locations___name_raw`, `mps_locations`.`estab_type` AS `mps_locations___estab_type`, `mps_locations`.`estab_type` AS `mps_locations___estab_type_raw`, `mps_locations`.`address` AS `mps_locations___address`, `mps_locations`.`address` AS `mps_locations___address_raw`, `mps_locations`.`city` AS `mps_locations___city`, `mps_locations`.`city` AS `mps_locations___city_raw`, `mps_locations`.`state` AS `mps_locations___state`, `mps_locations`.`state` AS `mps_locations___state_raw`, `mps_locations`.`map` AS `mps_locations___map`, `mps_locations`.`map` AS `mps_locations___map_raw`, `mps_locations`.`notes` AS `mps_locations___notes`, `mps_locations`.`notes` AS `mps_locations___notes_raw`, `mps_locations`.`url` AS `mps_locations___url`, `mps_locations`.`url` AS `mps_locations___url_raw`, `mps_locations`.`id` AS `mps_locations___id`, `mps_locations`.`id` AS `mps_locations___id_raw`, `mps_locations`.`date_time` AS `mps_locations___date_time`, `mps_locations`.`date_time` AS `mps_locations___date_time_raw`, `mps_locations`.`order_by` AS `mps_locations___order_by`, `mps_locations`.`order_by` AS `mps_locations___order_by_raw`, `mps_locations`.`edited_by` AS `mps_locations___edited_by_raw`, `btxz_users`.`name` AS `mps_locations___edited_by`, `mps_locations`.`edit_date` AS `mps_locations___edit_date`, `mps_locations`.`edit_date` AS `mps_locations___edit_date_raw`, `mps_locations`.`active` AS `mps_locations___active`, `mps_locations`.`active` AS `mps_locations___active_raw`, `mps_locations`.`backup_data` AS `mps_locations___backup_data`, `mps_locations`.`backup_data` AS `mps_locations___backup_data_raw`, `mps_locations`.`compare_backup` AS `mps_locations___compare_backup`, `mps_locations`.`compare_backup` AS `mps_locations___compare_backup_raw`, `mps_locations`.`id` AS slug , `mps_locations`.`id` AS `__pk_val` ,DISTINCT `mps_locations`.`id` AS __pk_val0 FROM `mps_locations` FROM `mps_locations` LEFT JOIN `btxz_users` AS `btxz_users` ON `btxz_users`.`id` = `mps_locations`.`edited_by` LEFT JOIN `btxz_users` AS `btxz_users` ON `btxz_users`.`id` = `mps_locations`.`edited_by` WHERE `mps_locations`.`id` IN ('29','11','46','32','102','8','41','58','71','56','92','91','12','99','5','68','118','110','111','97','90','27','50','93','53','61','103','112','70','95','2','39','115','74','81','3','116','83','64','59','22','114','48','10','88','33','13','60','7','28','76','106','66','94','40','80','63','96','4','117','120','55','35','72','105','82','54','31','16','42','49','87','1','57','101','47','107','69','19','44','26','36','52','34','6','23','119','100','113','109','73','20','24','51','45','89','104','25','79','75','77','37','98','78','65','9','43','18','67','17','21','108') ORDER BY `mps_locations`.`order_by` ASC

It seems this is somehow related to my setup so I am happy to troubleshoot further but I'm not sure where to begin.

 

[rackem]

In case you want to test on my site, you can use the "Test" Scheduled task. It is unpublished as I just have been running it manually for testing. Login info is present in "My Sites".

Using list 'Player Info' will generate a 504 Gateway time-out.
Using list 'Locations' will generate a 1064 error.
It runs as expected using list 'REF - Games".
The list 'Player Ratings' is the one I ultimately want to use for this task and is failing as well. It is joined to 'Player Info'.

Any suggestions for me to troubleshoot further are much appreciated as well.

 

[troester]

,DISTINCT `mps_locations`.`id` AS __pk_val0 FROM `mps_locations` FROM `mps_locations` LEFT JOIN `btxz_users` AS `btxz_users` ON `btxz_users`.`id` = `mps_locations`.`edited_by` LEFT JOIN `btxz_users` AS `btxz_users` ON `btxz_users`.`id` = `mps_locations`.`edited_by`

This whole part doesn't look right: there can't be a DISTINCT inside, FROM is doubled and LEFT JOIN is doubled, too.

I think you should select a php file in any case, it could be a dummy one just setting $processed.
You can include an
exit;
so maybe you'll see additional error messages (did you set Joomla error reporting to max?)

Is testing on your normal site? It seems the dev site is not available.

 

[rackem]

Yes, testing is on my normal site. The dev site is no being used right now, sorry.

I turned error reporting to max but no additional errors were reported. I moved the code to a PHP file and added an exit; There was no change to the behavior.

This part of the query seems odd too, I'm not sure where this is coming from. The attached pic shows my prefilters on this list

WHERE `mps_locations`.`id` IN ('29','11','46','32','102','8','41','58','71','56','92','91','12','99','5','68','118','110','111','97','90','27','50','93','53','61','103','112','70','95','2','39','115','74','81','3','116','83','64','59','22','114','48','10','88','33','13','60','7','28','76','106','66','94','40','80','63','96','4','117','120','55','35','72','105','82','54','31','16','42','49','87','1','57','101','47','107','69','19','44','26','36','52','34','6','23','119','100','113','109','73','20','24','51','45','89','104','25','79','75','77','37','98','78','65','9','43','18','67','17','21','108')

 

[troester]

The WHERE should be ok (the prefilter query is returning all ids matching the prefilter conditions).
I had a look at your "normal" locations list with Fabrikdebug

I see one thing where I'm not sure if it's correct

element filterValueList_Exact:
SELECT DISTINCT(`mps_locations`.`estab_type`) AS `text`, `mps_locations`.`estab_type` AS `value` FROM `mps_locations` LEFT JOIN `#__users` AS `btxz_users` ON `btxz_users`.`id` = `mps_locations`.`edited_by` WHERE `mps_locations`.`estab_type` IN ('1','0','2','3') ORDER BY text ASC

Which element type is estab_type?
From the query it loods like a dbjoin with key != id and a "data where" setting going to the list itself?

Edit: I assume it's coming from the dropdown filter.
Can you turn off this filter and test if this helps with the cron?

 

[rackem]

estab_type is a dropdown element with 4 options. There was no change in behavior after turning off the list filter.

A common feature between 'Player Info' and 'Location' lists is that they both have a dbjoin element to the #_users table called 'owner' and a user element 'edit_by' to keep track of recent changes. Note 'edit_by' is showing up in the duplicated LEFT JOIN. I had used these elements before to control & montior list edit access but am not doing that anymore. I tried unpublishing these element in the Location list but still receive the error below. The portions of the query related to these elements are gone but the duplicated FROM still remains.

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISTINCT `mps_locations`.`id` AS __pk_val0 FROM `mps_locations` FROM `mps_locati' at line 33 SQL=SELECT DISTINCT `mps_locations`.`name` AS `mps_locations___name`, `mps_locations`.`name` AS `mps_locations___name_raw`, `mps_locations`.`estab_type` AS `mps_locations___estab_type`, `mps_locations`.`estab_type` AS `mps_locations___estab_type_raw`, `mps_locations`.`address` AS `mps_locations___address`, `mps_locations`.`address` AS `mps_locations___address_raw`, `mps_locations`.`city` AS `mps_locations___city`, `mps_locations`.`city` AS `mps_locations___city_raw`, `mps_locations`.`state` AS `mps_locations___state`, `mps_locations`.`state` AS `mps_locations___state_raw`, `mps_locations`.`map` AS `mps_locations___map`, `mps_locations`.`map` AS `mps_locations___map_raw`, `mps_locations`.`notes` AS `mps_locations___notes`, `mps_locations`.`notes` AS `mps_locations___notes_raw`, `mps_locations`.`url` AS `mps_locations___url`, `mps_locations`.`url` AS `mps_locations___url_raw`, `mps_locations`.`id` AS `mps_locations___id`, `mps_locations`.`id` AS `mps_locations___id_raw`, `mps_locations`.`date_time` AS `mps_locations___date_time`, `mps_locations`.`date_time` AS `mps_locations___date_time_raw`, `mps_locations`.`order_by` AS `mps_locations___order_by`, `mps_locations`.`order_by` AS `mps_locations___order_by_raw`, `mps_locations`.`edit_date` AS `mps_locations___edit_date`, `mps_locations`.`edit_date` AS `mps_locations___edit_date_raw`, `mps_locations`.`active` AS `mps_locations___active`, `mps_locations`.`active` AS `mps_locations___active_raw`, `mps_locations`.`backup_data` AS `mps_locations___backup_data`, `mps_locations`.`backup_data` AS `mps_locations___backup_data_raw`, `mps_locations`.`compare_backup` AS `mps_locations___compare_backup`, `mps_locations`.`compare_backup` AS `mps_locations___compare_backup_raw`, `mps_locations`.`id` AS slug , `mps_locations`.`id` AS `__pk_val` ,DISTINCT `mps_locations`.`id` AS __pk_val0 FROM `mps_locations` FROM `mps_locations` WHERE `mps_locations`.`id` IN ('29','11','46','32','102','8','41','58','71','56','92','91','12','99','5','68','118','110','111','97','90','27','50','93','53','61','103','112','70','95','2','39','115','74','81','3','116','83','64','59','22','114','48','10','88','33','13','60','7','28','76','106','66','94','40','80','63','96','4','117','120','55','35','72','105','82','54','31','16','42','49','87','1','57','101','47','107','69','19','44','26','36','52','34','6','23','119','100','113','109','73','20','24','51','45','89','104','25','79','75','77','37','98','78','65','9','43','18','67','17','21','108') ORDER BY `mps_locations`.`order_by` ASC

This part of the query seems odd
`mps_locations`.`id` AS `__pk_val` ,DISTINCT `mps_locations`.`id` AS __pk_val0

Just to note also, there are no trashed elements hanging around.

 

[cheesegrits]

OK, the problem with the Locations was you had "merge and reduce" set on the Joins for the list, but no joins set up. So it was trying to use some logic on things which weren't there. Which means there's probably some code we should have a "if (!empty(...)) ..." around, but it'd take a long time to find it. So ... Don't Do That.

Now what it does is pitch a lot of warnings about not being able to load the static maps from Google. Not sure if that's us, or you've exceeded their rate limiting. But they are just warnings, so you should at least now be able to run code.

-- hugh

 

[cheesegrits]

What puzzles me is why your Locations list doesn't pitch that error when displaying it as a List. I think the query only gets malformed like, as a result of the "merge" being set with no joins, because when doing getData() from a cron plugin, because we run it in a slightly different mode, so it's not doing a lot of the "stuff" it usually does when it has to actually render the data in a list. So it takes a subtly different path through the query building.

So it really is very much a corner case, which I'm not going to go chasing.

-- hugh

 

[rackem]

Thanks for finding that improper setting in the Locations list. I will look into the Google map warnings but I'm not worried about them either at the moment.

Sorry if it wasn't clear but I am trying to get the 'Player Rating' list working with the cron.

Looking back, I spent more time explaining my troubleshooting and the end goal was unclear. I'll try to summarize. The cron is not working when pointing to 'Player Ratings' as desired; it is timing out with no indication why. I tried pointing to some other lists I use but had the same result. These lists all contain a join to 'Player Info'. I tried pointing the cron to that and it too times out. So that is why I assumed it was the likely source of the problem.

In my testing, I also found the 'Locations' list did not work either as well as lists that had a join to it. Note 'Locations' is an independent list from 'Player Info'. However, 'Locations' was at least providing an error message. I hoped fixing 'Locations' would provide clues to fixing the list I really wanted to work. Unfortunately, it appears to be a different issue.

The 'Player Info' list also had the 'merge and reduce' set as well and it too did not have any joins. I have changed that to 'each row separately' and tried it with the cron again but it is still timing out.



Is there a size limitation on the list's data when using crons? The lists I am trying to point to that aren't working have more data than the simple lists that do work. Nothing crazy, ~1,000s versus ~100s of rows.

Just a word on the cron, I am just looking for a well-traveled list to point to in order to crunch some data. I'm not actually using the list's data in the processing. There is a lot of processing and it isn't able to complete in a single run on my shared hosting. So it is set to run repeatedly (every minute) until it completes which takes several hours depending on the traffic to my list. Perhaps there is another way to accomplish this?

 

[rackem]

I think I've narrowed this down a little further...

I went into my 'test' cron, turned on the log and pointed it to my 'Player Info' list. The cron timed out as before and I checked the fabrik_log table in my database. Here is the query being generated.

SELECT SQL_CALC_FOUND_ROWS DISTINCT `mps_players`.`id` AS `mps_players___id`,
`mps_players`.`id` AS `mps_players___id_raw`,
`mps_players`.`date_time` AS `mps_players___date_time`,
`mps_players`.`date_time` AS `mps_players___date_time_raw`,
`mps_players`.`first_name` AS `mps_players___first_name`,
`mps_players`.`first_name` AS `mps_players___first_name_raw`,
`mps_players`.`first_plus_nickname` AS `mps_players___first_plus_nickname`,
`mps_players`.`first_plus_nickname` AS `mps_players___first_plus_nickname_raw`,
`mps_players`.`last_name` AS `mps_players___last_name`,
`mps_players`.`last_name` AS `mps_players___last_name_raw`,
`mps_players`.`sex` AS `mps_players___sex`,
`mps_players`.`sex` AS `mps_players___sex_raw`,
`mps_players`.`nickname` AS `mps_players___nickname`,
`mps_players`.`nickname` AS `mps_players___nickname_raw`,
`mps_players`.`alt_first_name` AS `mps_players___alt_first_name`,
`mps_players`.`alt_first_name` AS `mps_players___alt_first_name_raw`,
`mps_players`.`alt_last_name` AS `mps_players___alt_last_name`,
`mps_players`.`alt_last_name` AS `mps_players___alt_last_name_raw`,
`mps_players`.`first_last_alias_name` AS `mps_players___first_last_alias_name`,
`mps_players`.`first_last_alias_name` AS `mps_players___first_last_alias_name_raw`,
`mps_players`.`active` AS `mps_players___active`,
`mps_players`.`active` AS `mps_players___active_raw`,
`mps_players`.`automatch` AS `mps_players___automatch`,
`mps_players`.`automatch` AS `mps_players___automatch_raw`,
`mps_players`.`compare_backup` AS `mps_players___compare_backup`,
`mps_players`.`compare_backup` AS `mps_players___compare_backup_raw`,
`mps_players`.`lps_id` AS `mps_players___lps_id`,
`mps_players`.`lps_id` AS `mps_players___lps_id_raw`,
`mps_players`.`owner` AS `mps_players___owner_raw`,
`btxz_users`.`username` AS `mps_players___owner`,
`mps_players`.`notes` AS `mps_players___notes`,
`mps_players`.`notes` AS `mps_players___notes_raw`,
`mps_players`.`updated` AS `mps_players___updated`,
`mps_players`.`updated` AS `mps_players___updated_raw`,
`mps_players`.`edit_by` AS `mps_players___edit_by_raw`,
`btxz_users_0`.`name` AS `mps_players___edit_by`,
`mps_players`.`backup_data` AS `mps_players___backup_data`,
`mps_players`.`backup_data` AS `mps_players___backup_data_raw`,
`mps_players`.`order_by` AS `mps_players___order_by`,
`mps_players`.`order_by` AS `mps_players___order_by_raw`,
`mps_players`.`id` AS slug
, `mps_players`.`id` AS `__pk_val`

FROM `mps_players`
LEFT JOIN `btxz_users` AS `btxz_users` ON `btxz_users`.`id` = `mps_players`.`owner`
LEFT JOIN `#__users` AS `btxz_users_0` ON `btxz_users_0`.`id` = `mps_players`.`edit_by`
ORDER BY `mps_players`.`id` DESC

I ran this query through phpMyAdmin and got an error on this part.
LEFT JOIN `#__users` AS `btxz_users_0` ON `btxz_users_0`.`id` = `mps_players`.`edit_by`

It looks like the table name on my user element 'edit_by' is not being translated from '#___users'

So I removed and re-created the 'edit_by' element. Unfortunately there was no change - the query is still broken.

I also tried unpublishing the element and then the query works properly as that line is gone. However the task still times out.

 

[troester]

The # should be ok.
It's the same in the normal fabrikdebug: the debug query is created before # is replaced with your DB prefix.

Timeout:
What is you php max_execution_time? (-> increase)
Can you check directly in your DB if columns `mps_players`.`owner` and edited_by have indexes? (-> add)

 

[rackem]

The error I receives is 504 Gateway time out
Gateway Time-out
The gateway did not receive a timely response from the upstream server or application.

Here is what is in my hosting error log
[Mon May 11 08:33:58 2015] [warn] [client ...] Timeout waiting for output from CGI script .../administrator/index.php, referer: .../administrator/index.php?option=com_fabrik&view=crons

php max_execution_time is 120. However, I see the timeout after much shorter than 2 minutes, I'd say its closer to 30 sec. The mysql.connect_timeout is 20. Perhaps it is a mysql timeout but I'm not seeing any significant delays when view my list or run queries on this table manually.

I can't increase these as I am on SiteGround shared hosting. Just to reiterate, a cron was working before on this list.

I've looked through the other various log files on my site and don't see anything that looks related.

`owner` had an index and `edit_by` did not. Now they both do but the timeout still occurs.