I just realized that there are a whole bunch of ReportLog objects sitting in the production server because appengine ran out of time to run report_handler.py :( When appengine cold-starts, it takes extra time to compile the scripts and end up not being able to finish the request. As someone worked on the flakiness dashboard suggested before, we should do the whole parsing, processing, etc... in background instead. We also need some UI to salvage the lost reports.
Created attachment 126471 [details] Patch
Created attachment 126472 [details] Removed report_logs_handler.pyc
Comment on attachment 126472 [details] Removed report_logs_handler.pyc View in context: https://bugs.webkit.org/attachment.cgi?id=126472&action=review I really want to see the unittest. for this. You can test datastore even locally. http://code.google.com/appengine/docs/python/tools/localunittesting.html > Websites/webkit-perf.appspot.com/report_logs.yaml:1 > +<!DOCTYPE html> This doesn't look like a yaml at all.
(In reply to comment #3) > (From update of attachment 126472 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=126472&action=review > > I really want to see the unittest. for this. > You can test datastore even locally. > http://code.google.com/appengine/docs/python/tools/localunittesting.html I don't think testing model code is interesting since most of the logic lives in handler classes at the moment. > > Websites/webkit-perf.appspot.com/report_logs.yaml:1 > > +<!DOCTYPE html> > > This doesn't look like a yaml at all. What do you mean?
FWIW, this code has been pushed into the production.
Created attachment 126476 [details] Fixed yaml > html
Committed r107386: <http://trac.webkit.org/changeset/107386>
Build fix landed in http://trac.webkit.org/changeset/107393.