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!