A patch of mine introduced several exceptions per page load (ie. a lot of exception assertions), which led to PIFR blowing up: the patch was cycling "Requested by test client #32.", "Result received from test client #32.", "Test reset by client request." until I stopped it.
It seems that something is dying because the dataset is too large. This is obviously wrong:
$count = count($database->query('SELECT * FROM {simpletest}'));
return t('Running tests, @count assertion(s).', array('@count' => number_format($count)));
... but there might be other places where the size of the dataset matters.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 669230-batch-assertions.patch | 4.63 KB | boombatower |
Comments
Comment #1
damien tournoud commentedSee what happens... http://qa.drupal.org/pifr/test/23376
Comment #2
damien tournoud commentedComment #3
cburschka*gibbers* there... there is a perfectly good reason for not using countQuery(), right?
Comment #4
cburschkaOops.
Comment #5
int commentedI don't know if is related.
In the QA, if you click in Core status you will see one error.
Core status
Comment #6
int commentedcross-post
Comment #7
damien tournoud commented@int: no, that doesn't seem related.
Comment #8
damien tournoud commented@Arancaytar: this is plain PDO, we don't have our database layer here, so we don't have countQuery()... but we can obviously use COUNT() :)
Actually, I don't believe this is the main issue: this silly query makes the admin interface fail with an Out of memory error, but the error that causes the reset of the test seems different. I think the generated XML message is too big and cannot be parsed by the test master.
Comment #9
int commentednow that Core Status pass without fails, the testbot works again.
Show the cycle tests, and then the manager requested to the HEAD(of Core Status) be re-tested, and then work again.
http://qa.drupal.org/pifr/log/recent
Comment #10
boombatower commentedCurrent the code cycles through all the assertions and counts them up (among other things) during get_result().
Since it was already cylcing through them doing count() shouldn't be any worse. The reason for not using COUNT() in query was just that it was simpler to use a standard query() that returns an array, and something that was changed for sqlite backend that you were involved in, #441588: SQLite driver. Not so obvious I guess. :)
Anyway, so either have the database perform all the counts and/or add some sort of paging query type code for get_results().
Comment #11
boombatower commentedWorking on it.
Comment #12
boombatower commentedThis problem only occurs after the sqlite backend and the change, since before that we had a patch go through with over 800,000 exceptions.
This patch still runs normally and from logic change would appear to fix your issue.
Comment #13
boombatower commentedCommitted.