When I visit this page I get the following: http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul ++++++++ Page not found (404) Request Method: GET Request URL: http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul No TestFailure matches the given query. You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 404 page. ++++++++ There is a test failure in the following log and I expected it to show up: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1273648598.1273649788.12380.gz This is the bug tracking the failure since Nov. 2009: https://bugzilla.mozilla.org/show_bug.cgi?id=527099

These results are not yet picked up by the cron job. Currently, the cron job runs twice a day. I will make sure that the cron job changes to once every 3 hours before EOD today

Murali, this is not WFM. You absolutely cannot show the Django debug output as an error message. You'll still need a real error message here, even if you up the frequency of the cron job. Please morph this bug to add such an error message.

OK.

I think the original purpose of this bug is being side-tracked. When I try to see the test failures for: chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul Should I get to see it by visiting http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul ?

Looking at the history in bug 527099, it seems that this failure should have shown up in the topfails db even though the scraper runs only twice per day, since it also occurred on, e.g., May 9. So this may be a problem with the log scraper, instead of just the fact that the data can be up to 12 hours old. I'm assigning this to jhammel since he owns this component going forward.

The DEBUG issue is fixed now; the body of the bug, not so much

Jeff .. I presume that you are working on the logic to parse the log file pertaining to this issue. Cheers Murali

(In reply to comment #7) > Jeff .. I presume that you are working on the logic to parse the log file > pertaining to this issue. > > Cheers > Murali Not right at the moment. Why?

So going through this bug, a number of issues are being conflated. I'm going to try to sort them out: - this bug is being used as a tracking bug for several different cases where topfails doesn't find the error in the log. Is this what we want to do? if yes, then we should change the title to something more appropriate. If not, then we should file separate bugs for each case where it fails - for each case when it fails, a the log that contains the failure should be uploaded and verbosely which error topfails doesn't find should be described. Without this debugging information, it will be impossible to reproduce and fix. (Not meant as an excuse, but fixing topfails is not on my high-priority tasks for this quarter, so I don't have time to hunt for bugs in logs and debug + fix topfails.) Those I think are the two action items.

I am not using TopFails anymore so there is nothing from me to add. It is up to the rest to (In reply to comment #4) > I think the original purpose of this bug is being side-tracked. > > When I try to see the test failures for: > chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul > > Should I get to see it by visiting > http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul > ? The page works for me showing me the test failure occurred on "Rev3 WINNT 6.1 mozilla-central opt test mochitest-other". I thinks this is WORKSFORME or RESOLVED FIXED; isn't?

(In reply to comment #10) > I am not using TopFails anymore so there is nothing from me to add. It is up to > the rest to (In reply to comment #4) > > I think the original purpose of this bug is being side-tracked. > > > > When I try to see the test failures for: > > chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul > > > > Should I get to see it by visiting > > http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul > > ? > > The page works for me showing me the test failure occurred on "Rev3 WINNT 6.1 > mozilla-central opt test mochitest-other". > > I thinks this is WORKSFORME or RESOLVED FIXED; isn't? Yeah, that exists now. But see comment 9.

(In reply to comment #11) > (In reply to comment #10) > > I thinks this is WORKSFORME or RESOLVED FIXED; isn't? > > Yeah, that exists now. But see comment 9. I will let others answer as I am not anymore a stake-holder for TopFails as I am not anymore a user of it.

(In reply to comment #9) W.r.t. the dependent bugs I added, I think they explicitly contain the errors and/or the link to the logs. W.r.t TopFails missing some test failures, I would hope there could be a way for TopFails to compare its parsing results with the (failed) test summary in the log, then "warn" if the two numbers differ in an unexpected way. NB: Same comments apply to bug 564234.

this dependencies of these bug have been used to denote additional log parsing issues. Changing the bug title to correctly note bug intention.

topfails has been supplanted by the Orage Factor: - https://wiki.mozilla.org/Auto-tools/Projects/WarOnOrange - http://brasstacks.mozilla.com/orangefactor/ This uses a greatly improved log parser: - https://wiki.mozilla.org/Auto-tools/Projects/Autolog - http://hg.mozilla.org/automation/logparser/ We've turned off the topfails server. If there are any addition needs for Orange Factor, please file them in the Testing::Orange Factor component.