How can MySQL queries come in the wrong order? - php

Question

I have some code that creates a user and later down the line it checks if the user is real. Essentially this:
// INSERT statement fired in here
$user = self::_createUser( $params );
// Performs a sanity check by hitting DB with
// SELECT for the ID returned from creation within object
if ( !$user->isReal() ) {
throw new Exception( "User failed to create: " . var_export( $params, 1 ), MYCODE );
}
Since the user was just created this exception should never be thrown. This never happens in production, or my sandbox environment. However our test environment uses Jenkins to kick off multiple tests at once, where the lines above live.
The exception will be thrown at random, on different tests at each run of our suite.
We turned on all MySQL logging and found that the sanity SELECT is being called BEFORE the INSERT however the SELECT is clearly selecting the proper ID from the DB - which it couldn't have unless the create worked.
How can MySQL server randomly receive a query in the wrong order? Never seen anything like this before.
EDIT Here is more code for clarification
function _createUser( $params ) {
// db returns connection using Zend, which translates to something like
// INSERT INTO users SET name='a'
// Returns ID of row inserted
$this->_id = self::db()->insert( 'users', $params );
}
function isReal() {
// Returns false when row is not there
return self::db()->fetchRow( "SELECT * FROM users WHERE id={$this->_id}" );
}
Also the MySQL logs show the query as I expect in all cases, with NO DEFER
EDIT 2
Using command line rather than Jenkins to run tests parallel is still making this happen.
Meanwhile it will only run up to 7 tests at the same time, and there no where in the code that would delete the user at the time. There are no blanket deletes except BEFORE all the tests run.
EDIT 3
Okay so in the tests that run, there are some persistent connections. One is for MySQL and one is for Mongo. Before my suite runs it was wiping MySQL by rebuilding DB from scratch, and erasing memcache. It was not doing this for mongo and thus was causing some other random errors. Once I added mongo to the reset script, it seems that the MySQL errors went away. This makes zero sense to anyone on my team or myself. Can anyone make sense of that?

Answer 1

I don't know why, but two days later, this error went away. It went away like my 3rd edit said... after I made sure that when I emptied MySQL and memcache, I also emptied mongo. The best guess I have is that when bad mongo data caused an exception, PHP sputtered in some way. Not sure if it's a PHP bug or if I'd sound crazy trying to report it.
Although I'm posting this answer, I'd still appreciate any additional input.