Configuration schema errors whilst updating to 8.3.0

#2867113-11: Fatal error in serialization_update_8302() when updating to 8.3.0-rc2 reported this first:

PHP Fatal error:  Call to undefined method Drupal\Core\Config\Schema\Undefined::get() in /.../core/lib/Drupal/Core/Config/StorableConfigBase.php on line 179

The IS/STR also confirm this exact fatal error.

#4 referred to editing link_domain in rest.settings prior to updating from 8.2.x to 8.3.0. So, looked into that a bit. A few observations:

1. Note that rest.settings until before 8.3.0 has this:
   

   link_domain: ~
   

2. This is in rest.schema.yml, in 8.3.0:
   

   # Schema for the configuration files of the REST module.
   rest.settings:
     type: config_object
     label: 'REST settings'
     mapping:
       # @deprecated in Drupal 8.3.x and will be removed before Drupal 9.0.0.
       link_domain:
         type: string
         label: 'Domain of the relation'
   

   i.e. link_domain is still there, specifically to not break config schema during upgrades.

3. And this is in hal.schema.yml, in 8.3.0:
   

   # Schema for the configuration files of the HAL module.
   hal.settings:
     type: config_object
     label: 'HAL settings'
     mapping:
       link_domain:
         type: string
         label: 'Domain of the relation'
   

   i.e. the same.

4. The error in the IS/STR is triggered by this code:
   

     protected function castValue($key, $value) {
       $element = $this->getSchemaWrapper()->get($key);
   

   Since it says Undefined::get() does not exist, getSchemaWrapper() must be returning an instance of \Drupal\Core\Config\Schema\Undefined, and that seems to be incorrect based on it being assigned the string type.

I don't know configuration system/configuration schema system internals well enough to make any educated guesses.

Adding the workaround alexpott found to the summary. Assuming this was not assigned to catch on purpose.

Apparently this happens when the whole config object itself has no type.

What I don't quite understand is that the call to this is wrapped in

if ($this->typedConfigManager->hasConfigSchema($this->name)) {
]

So if we have config schema then the type must always be a container and should always implement TypedConfigInterface.

It looks like we an inconsistency between that check and actually getting/creating a data definition? Are we clearing one cache but not the other?

If this is a real unexpected error condition then while the fatal is bad I'm not sure we should be that defensive, it could result in bad data in different circumstances.

Should we not just trust the data when we save the rest config entities in the post update?

This isn't hook_update_N() though, it's a post update that's supposed to have a full environment available. Not sure whether there's a use case to want schema in that case but maybe in the load and resave case to get things casted properly

If this was fixed in February (in https://github.com/drush-ops/drush/issues/2617), what do we want to do here?

We could:

1. Commit this anyway since we trust the data
2. Re-purpose it to be a more useful error

Is it worth adding a note like 'If you're updating directly from 8.1.x to 8.3.x you should update drush first' to the release notes, on the other hand you're not really supposed to update from 8.1.x to 8.3.x directly.

Hm.

According to the report in #2867113: Fatal error in serialization_update_8302() when updating to 8.3.0-rc2, the person reporting that problem did not have drush installed at all. So it possibly isn't something *only* triggered by drush?

We probably need more info on previous version, installed modules, ..

That was a hook_update_N(), this is a hook_post_update_FOO(), the important thing with this issue is the full cache clear/rebuild before the post updates run, which drush wasn't doing correctly. Enforcing schema in hook_update_N() needs to be ruled out possibly since we can't do a clean cache rebuild then so much.

Either way we do need to do something here about alternative code paths even if it's just better error handling.

I can't find anything in the comments from MmMnRr over there that he was running into a problem with the same update function as you did?

I tried to run update.php again and for no reason it worked perfectly now.
So the issue is solved.

I tried multiple times to run update.php and I always received the same error. But now it worked.

I do not have drush installed in my server yet.
The trace came from the Apache log.
I checked the specific line referenced in the trace and it is the following:

(From the other issue.)

So it's not only drush, then.

#2861863: InvalidArgumentException "Field is unknown" in ContentEntityBase is another totally different fatal that goes away when running database updates multiple times. Hmm.

Hi all,

I was trying to update from Drupal 8.1.1 to Drupal 8.3.0.
I do not have the full trace because I do not have drush installed. The only error message I got appeared on Apache log:

PHP Fatal error:  Call to undefined method Drupal\Core\Config\Schema\Undefined::get() in /.../core/lib/Drupal/Core/Config/StorableConfigBase.php on line 179

I followed the official Drupal Core update instructions:
https://www.drupal.org/docs/8/update/update-procedure-in-drupal-8

I tried to run update.php several times and it always failed.
Then I navigated through the website pages and tried again. The update worked perfectly then. Maybe the navigation triggered something but I have no proof.

The specific line referenced in the trace is the following:

/.../core/lib/Drupal/Core/Config/StorableConfigBase.php

protected function castValue($key, $value) {
    $element = $this->getSchemaWrapper()->get($key);

As the update has been done correctly now, I am unable to reproduce again the issue.

@alexpott The Apache log only included that message. Unfortunately, I do not have a more complete full stack trace.

This issue concerns updating to a now non-supported Drupal version. I think that makes this outdated, closing as such.

Thanks folks!