Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
https://www.drupal.org/pift-ci-job/1162569
There's a test over in #3023504: Add test coverage for drush config export. The reason why this seems to be failing is that we are trying to generate a config entity in core inside of the profile field migration's getProcess method and that is failing. Config entities can not be stubbed, and that's what it is trying to do.
Proposed resolution
Don't throw a skip row exception. Return an empty process in getProcess if requirements aren't met. In this case, requirements are that the previous migrations have finished.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#17 | interdiff.3023747.9-17.txt | 3.25 KB | mikelutz |
#17 | 3023747-17.drupal.D6-profile-migrations-assume-stubs-which-fail.patch | 4.78 KB | mikelutz |
Comments
Comment #2
heddnComment #3
mikelutzTest Only Patch. Migration::getProcess() should never throw an exception. It should return a process, or an empty array, but not an exception.
Comment #5
mikelutzwhoops. test patch again.
Comment #6
mikelutzComment #7
heddnSeems there are some stray changes in here.
Comment #9
mikelutzI don't know why my diffs got borked, but let's try one last time...
Comment #11
heddnI think this should be 'required'.
Fixed here in new patch. And marked RTBC as most of these changes are not mine, except for the minor doc improvement. The solution opted for here is a much cleaner/better route than what was there before.
Comment #12
heddnComment #13
heddnComment #14
mikelutzTesting against 8.6 as well, this should be backported.
Comment #15
heddnComment #16
heddnRe-reviewing things here. Having second thoughts.
Might want to catch for Exception?
This is still getting thrown. Is that fine or should we log an error and continue? Just because one field cannot migrate doesn't mean we should bail the whole migration? Or should it? I checked, and the skip row will cause the entire migration to fail.
Comment #17
mikelutzI caught the skipRow exception in particular because I wanted the fail message to tell me which migration was failing, but any Exception would fail the test. Still, might as well have the message for all exceptions.
We really need to inject loggers into the migration system in general, but I don't want to add one for this issue. I don't see any real way for that exception to be thrown, we are looping through the same source data as the migration we are looking up, and we know that migration ran, so if we don't get a result, there's something corrupt with the source data. I think it is reasonable to just skip the field in that case, because if the lookup failed then the field didn't get created anyway, so there's nothing to migrate to.
Comment #18
mikelutzComment #19
heddnAssuming this comes back green, we be good to go. The rational for removing the skip exception (and not replacing with logging) make sense. No need for a follow-up in here, because we shouldn't see the situation. We have a check requirements call earlier and the sources are the same.
Comment #20
catchFixed this on commit:
Committed and pushed 95b3b17867 to 8.7.x and 305fd92394 to 8.6.x. Thanks!