Showing results for 
Search instead for 
Did you mean: 
Community Member


Hi all, 

I posted this question elsewhere but thought perhaps it could have it's own thread. If I'm wrong go ahead and delete me. Anyways, I recently watched Canvas' accessibility video and was thrilled to learn about UDOIT. We have been using Sitemorse's snapshot which is unable to run in java so we were having to copy/paste HTML code and it was just a pain. 

However after going through and successfully deploying UDOIT to heroku I consistently get the same error: UDOIT failed to scan this course. 

Has anyone else experienced anything like this? I'm unsure of where to go from here. It's really disappointing because there's just nothing else like this in Canvas and it sees like it is an incredibly powerful tool. 

61 Replies

I'm out at a conference right now, but I'll take a look at this when I get back next week.  Does this error happen immediately, or does it happen after an amount of time that would make sense for the amount of content it's scanning?  Also, are you running this on your own server, or on Heroku?

Thanks Jacob. The error happens after a period of time....We are hosting on our own server.

A few things that can cause this issue:

  • Lots of YouTube videos in the pages.  UDOIT has to talk to YouTube individually for each one.
  • Lots of files in the course.  Try clearing out unneeded files if this is the case.  If you can't delete any files, try running the scan on the Pages only.
  • Funky code on one of the pages that UDOIT doesn't know how to handle.  We have worked hard to fix all of these cases, but they still come up from time to time.  Check out the pages to make sure there's nothing funky going on with the HTML.  You can also check your server logs to see if UDOIT spit out a PHP error.

Regardless, you (or your server admin) should pull the PHP and web server logs right after encountering the failure to see if anything popped up.

Also, I highly recommend updating to Release v2.2.0 of UDOIT.  This issue might have been fixed in that release.

Community Coach
Community Coach

We just got UDOIT set up in our "Test" environment of Canvas.  We have done the local installation of UDOIT on our own servers vs. installing through Heroku.  For some courses in our "Test" environment, the scan works beautifully!  Reports come back in a few seconds.  For other courses, however, we are getting screens like:


Sometimes it will list things like "pages" and "files" with "2 left to scan".  It takes several minutes for the number to go down to zero...such as this:


I've let the scan continue running for at least 30 minutes...if not longer...and nothing has changed.  I'm not sure why some courses are scanning properly (and quickly) while others take a super long time.  Could this be because we're using our "Test" environment vs. "Production"?

Has anyone else seen things like this?  I've e-mailed tr_jbates‌ to see if he has any thoughts on this.

Chris:  These issues might be caused by some bugs in our 2.3.0 release.  Please investigate/change the following items and let me know if that fixes the issue:

  • In the "reports" table, add a "report_json" field of type "MEDIUMTEXT" if it does not already exist. If it already exists, change the type to "MEDIUMTEXT"
  • In the "job_queue" table, make sure the "results" field is of type "MEDIUMTEXT"

tr_jbates‌ thank you for that reply - in job_queue ours was text and I changed it to mediumtext and our problem is solved

after looking at the table schema, I first backed up the database, then changed that column. Code for backup and alter table are here, in case it helps anybody. Requires a basic understanding of sql and of course substitute your own database name and export file name. the --password switch will prompt for your database password when it runs

First, this will back up your database in case something goes wrong

mysqldump --database udoit -u root --password > backup-file-name.sql

and then this will change that field to mediumtext
 ALTER TABLE job_queue CHANGE results results mediumtext;

That's great to hear, and thanks for providing the SQL.  The changes will be incorporated into the 2.3.1 release, which will come out very soon.  I'll include these instructions for those who have installed 2.3.0 already.

We just released which should take care of the migration script issues.  It still requires manual fixing for anyone who already installed 2.3.0.

We are experiencing the exact same issue as Chris Hofer described:


We are self hosted and have upgraded to the latest 2.3.1 version and the issue is still occurring. We implemented the MEDIUMTEXT fix and that didn't work either. Any help at all would be much appreciated, thank you! 

Just to confirm:  You added a "report_json" field of type MEDIUMTEXT to the "reports" table, and you verified that you have a "job_queue" table, and the "results" field is of type MEDIUMTEXT?

Also, if you have access to your error logs (php, NGINX, and/or Apache), please email them to me at