Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
base system
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
6 Dec 2009 at 07:23 UTC
Updated:
8 Jan 2010 at 01:10 UTC
Jump to comment: Most recent file
This is required to release D7 and #652394: Aggressive watchdog message assertion ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | drupal.various-response.patch | 3.57 KB | sun |
| #10 | drupal.various.10.patch | 12.05 KB | sun |
| #8 | drupal.various.8.patch | 12.05 KB | sun |
| #5 | drupal.various.5.patch | 4.9 KB | sun |
| #2 | drupal.various.2a.patch | 4.9 KB | sun |
Comments
Comment #2
sunComment #3
dries commentedAre you sure you want to call drupal_exit() and not 'return'? I'd have to dig a bit deeper but it could affect some callbacks not being called.
It might be slightly better to move %file to appear later in the string. We only see x characters on the watchdog overview page and I'm worried that we'd see the filename only. We should lead with the part of the message that provides context.
Comment #4
sun1) http://api.drupal.org/api/function/drupal_exit/7 and http://api.drupal.org/api/function/drupal_page_footer/7 are almost identical, except that drupal_page_footer() additionally tries to serve from cache as well as to update a couple of shutdown caches. Both not required for 403 and 404 pages. Actually, we now use drupal_exit() everywhere in Drupal in such situations.
2) Doable.
Comment #5
sunFixed 2).
Comment #6
dries commentedCommitted to CVS HEAD. Thanks!
Comment #7
sunHm, the actual output of that watchdog message is:
http://qa.drupal.org/pifr/test/21800
But I don't think the original $file is passed... So we either make it pass the original file or we drop the filename (but then the entire watchdog message wouldn't make much sense)
Comment #8
sunThere some more easily fixable failures. Not yet sure what to do about aforementioned watchdog(), but we can continue to fix the other fails in the meantime.
That said, something is horribly wrong with PIFR's error logging. The same drupal_cache_system_paths() function in path.inc that we already touched in the last patch now threw another PHP warning that wasn't contained before. :-/
Fixes some senseless assertions in Locale tests.
But we also have some watchdog errors (403) in the new HTTPS functionality test. Problem: I don't understand this test, so I can only fix the obvious.
Comment #10
sunerrr. Fixing that false-fixed-failing-test. ;)
Comment #11
webchickI reviewed #10 with sun in IRC:
I asked about:
This means "post back to the current page." I'm sure if I had the drupalPost docs in front of me rather than reading a patch file, I would know that. ;)
I was also concerned about how often this patch adds lines like this:
...and how to explain to test authors when they need to do so.
sun explained that you do these explicitly when your test depends on a 404/403 response; for example, while testing that the search block appears on the 404 page.
Committed #10 to HEAD, marking back to active.
Comment #12
carlos8f commentedEr, am I going crazy or does this assertNoResponse() method not exist in simpletest? All the tests that use this method fail with:
Isn't the method supposed to be in drupal_web_test_case.php? http://drupalcode.org/viewvc/drupal/drupal/modules/simpletest/drupal_web...
Comment #13
sunerrrr - WTF? Either that existed previously, or this API is totally inconsistent.
Thanks! Let's fix the fatals first. :-/
man... we absolutely need to get #653940: Clean-up: Tests do not report all errors done. This is insane. I can introduce fatal errors, warnings, and notices, and absolutely nothing tells me. Totally insane.
I'd even consider to commit #653940: Clean-up: Tests do not report all errors _now_. ALL patches in the queue and all developers and all maintainers are relying on a testing system that does not report errors. That's unacceptable.
Comment #14
carlos8f commentedagreed! that was really weird. glad i wasn't crazy.
Comment #15
carlos8f commented#13 fixes the fatals in HEAD, let's get it committed then set back to active.
Comment #16
catchYep. Slightly more quick-commit friendly issue-title too ;)
Comment #17
dries commentedCommitted to CVS HEAD. Thanks.
Comment #18
catchBack to the remainder of #10.
Comment #19
catchAnything but normal.
Comment #20
sunNote that I deferred the work on #652394: Aggressive watchdog message assertion and prioritized #653940: Clean-up: Tests do not report all errors, because there are a couple of watchdog messages in the former test results that I cannot really explain. In the latter, I was able to reveal
3 fail(s), and 13,051 exception(es)
in the current code and already brought that down to
0 fail(s), and 123 exception(es)
However, I need some OOP help though, because most of the remaining exceptions are caused by wrong testing class method invocations.
Comment #21
c960657 commentedIt looks like #13 wasn't committed. Instead the patch for #459786: countQuery() should also remove all_fields statements was committed twice by mistake. The last commit message had a reference to this issue.
Comment #22
dave reidConfirmed this absolutely broke core testing.
Comment #23
carlos8f commentedConfirmed #21 that #13 wasn't committed. Changing the title back with some emphasis.
Comment #24
dries commentedCommitted to CVS HEAD. For real now. The network at DIDW is really unreliable so sometimes things hang for minutes.
Comment #25
carlos8f commentedChanging title to something a little more descriptive :D
Comment #26
sunI think that, for now, no hidden errors are remaining from that other patch.