The following failure occurs in legacy integration tests when ran against MySQL backend:

eZ\Publish\API\Repository\Tests\ContentServiceTest::testPublishVersionCreatesLocationsDefinedOnCreate
eZ\Publish\Core\Base\Exceptions\NotFoundException: Could not find 'location' with identifier '0123456789abcdef0123456789abcdef'

/home/eddie/ezp-next/eZ/Publish/Core/Persistence/Legacy/Content/Location/Gateway/EzcDatabase.php:105
/home/eddie/ezp-next/eZ/Publish/Core/Persistence/Legacy/Content/Location/Gateway/ExceptionConversion.php:74
/home/eddie/ezp-next/eZ/Publish/Core/Persistence/Legacy/Content/Location/Handler.php:110
/home/eddie/ezp-next/eZ/Publish/Core/Repository/LocationService.php:201
/home/eddie/ezp-next/eZ/Publish/API/Repository/Tests/ContentServiceTest.php:891

Background story:

In eZ Publish 4 it is not possible to set the remote ID of the node when publishing an object, while in PAPI it is possible to do so.

To employ such functionality in PAPI, eznode_assignment.remote_id field is used to store the user defined remote ID between creating a draft and publishing it, when it is copied over to ezcontentobject_tree.remote_id. In eZ Publish 4, eznode_assignment.remote_id is empty after publishing an object (i.e. not used)

Issue with this approach in PAPI is that eznode_assignment.remote_id is int(11), while ezcontentobject_tree.remote_id is varchar, which makes it impossible to create non numeric remote IDs, which the failing test does.

This test passed while running integration tests on sqlite backend because SQLite stores and reads integers internally as strings.