Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Right now, if something happens that prevents a destination object from saving (particularly SQL errors like integrity constraint violations), all we're able to save in the messages table for the most part is "New object was not saved, no error provided". We should set an error handler at the beginning of Migrate::import, which will call Migrate::saveMessage for notices and throw an exception for anything else.
Comments
Comment #1
mikeryanWell, the basic concept works, but the primary motivation here doesn't - db exceptions are caught and rerouted to the watchdog via a "logging callback". We can set such a callback, but because the callback is called as a variable function rather than via call_user_func(), we can't make the callback a class method, it needs to be a straight function. When I have a chance, I'll see if I can submit a core patch making logging callbacks proper PHP "callback" types, called via call_user_func().
Comment #2
mikeryanCore patch submitted: #748982: Allow Database logging_callback to be a class method
Comment #3
mikeryanLong since fixed.
Comment #4
mikeryanAnd now broken by #711108: Richer exception reporting for watchdog()...
Comment #5
mikeryanWe can catch these in hook_watchdog(), which may be a more general way to pick up errors anyway, but it has to be able to figure out the Migration instance that resulted in the call. Perhaps scan all migrations for processing == TRUE?
Comment #6
mikeryanFinal issue addressed by Migration::currentMigration().
Comment #8
pengo commentedI'm still getting "New object was not saved, no error provided" on a file migration (migrate 7.x-2.5+32-dev). Struggling to debug.