Brion Vibber wrote:
Pasting below from the pad. Sorry, I trust the mailing list archives more
than I trust Etherpad. (Do Etherpads have a license for contributions to
them? Is it assumed to be the same as wiki contributions?)
MZMcBride
----
First: fix for bogus load of non-matching id: r90137
This bug was showing up in test results like this:
BlockTest::testInitializerFunctionsReturnCorrectBlock
Trying to get property of non-object
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/includes/Block.php:340
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/includes/Block.php:365
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/includes/Block.php:118
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/includes/B
lockTest.php:60
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiT
estCase.php:60
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiP
HPUnitCommand.php:20
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/phpunit.ph
p:60
However, that only triggers because the actual test is failing -- it's
expecting to get a return back. This can only be reproduce when using the
suite.xml configuration file, and not when running the BlockTest
standalone.
Here's what seems to be happening from there...
* the test tries to load up a previously-inserted block by id, BUT IT HAS
NULL INSTEAD OF THE ACTUAL ID
* due to a weird, totally non-obvious MySQL server setting, the query
looking for NULL matches the last-inserted autoincrement value ... which is
what the caller expected, thinking it had an actual number to look up
* for some reason, that gets disabled when running with the suite.xml
configuration -- possibly additional setup/teardown is happening that
disrupts it, or the setting is getting turned off
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_s
ql_auto_is_null
http://dev.mysql.com/doc/refman/5.0/en/comparison-operators.html#operator_is
-null
Running straight from php phpunit.php includes/BlockTest.php:
SELECT /* Block::newFromID 127.0.0.1 */ * FROM `unittest_ipblocks` WHERE
ipb_id IS NULL LIMIT 1
FOUND: stdClass::__set_state(array(
'ipb_id' => '1',
'ipb_address' => 'UTBlockee',
'ipb_user' => '2',
'ipb_by' => '0',
'ipb_by_text' => '127.0.0.1',
'ipb_reason' => 'Some reason',
'ipb_timestamp' => '20110615191308',
'ipb_auto' => '0',
'ipb_anon_only' => '0',
'ipb_create_account' => '0',
'ipb_enable_autoblock' => '0',
'ipb_expiry' => 'infinity',
'ipb_range_start' => '',
'ipb_range_end' => '',
'ipb_deleted' => '0',
'ipb_block_email' => '0',
'ipb_allow_usertalk' => '0',
))
Running with php phpunit.php --configuration=suite.xml --filter=BlockTest:
SELECT /* Block::newFromID Sysop for Media... */ * FROM
`unittest_ipblocks` WHERE ipb_id IS NULL LIMIT 1
FOUND: false
Looks like Block::insert isn't saving the new block id in -- this needs to
be retrieved via $dbw->lastInsertId() or such (the nextSequenceValue()
usually gives us null on MySQL since we implement sequences using
auto_increment columns)
Fix there may clear it up: r90146
.... and following down from there once fixed, we found the FINAL problem
was that the setup got run multiple times, and on later runs we were unable
to re-add the already-existing block row so ended up with a bogus result.
Deleting any conflicting block first seems to have resolved it: r90147
Yay!