Block config changes not saved in 10.1.x

Can you reproduce this with just vanilla Drupal core?

I just tried, and cannot. Standing up a vanilla Drupal 10.1.7 site results in a block config save acting as it should.
Any idea of what to look for that might be impacting a config save that has changed from 10.0 to 10.1?

This incomplete bug report is similar: 🐛 Regression from #3341682: #states + #required do not automatically work together, resulting in an unsubmittable AccountSettingsForm Fixed .

When I click the submit button in the block config form, stepping through in xdebug, I reach ::submitConfigurationForm() in BlockPluginTrait.

At this point $form_state contains the changed block title in $form_state->decoratedFormState->values[settings][label].

::blockSubmit() is then called.

It progresses to FormBuilder::buildForm() where ::processForm() is called and returns an EnforcedResponseException code of 303 (Other).

No error message is given on the screen, nothing logged, but the result is a return to the block layout screen with the config change not having been saved.

The 303 was a red herring. I'd gone too deep in debugging.

I've found in putting a breakpoint in BlockPluginTrait::setConfiguration that in a vanilla instance the change to the title in the block config form is reflected here, but not in the problem instance. I've pasted the call stack trace below. I'd greatly appreciate being pointed at a likely next place to look.

Stack: 
BlockPluginTrait.php:80, Drupal\Core\Block\BlockBase->setConfiguration()
DefaultSingleLazyPluginCollection.php:85, Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->setConfiguration()
ConfigEntityBase.php:165, Drupal\Core\Config\Entity\ConfigEntityBase->set()
ConfigEntityBase.php:295, Drupal\Core\Config\Entity\ConfigEntityBase->preSave()
Block.php:344, Drupal\block\Entity\Block->preSave()
EntityStorageBase.php:528, Drupal\Core\Entity\EntityStorageBase->doPreSave()
EntityStorageBase.php:483, Drupal\Core\Entity\EntityStorageBase->save()
ConfigEntityStorage.php:257, Drupal\Core\Config\Entity\ConfigEntityStorage->save()
EntityBase.php:339, Drupal\Core\Entity\EntityBase->save()
ConfigEntityBase.php:609, Drupal\Core\Config\Entity\ConfigEntityBase->save()
EntityForm.php:293, Drupal\Core\Entity\EntityForm->save()
FormSubmitter.php:114, call_user_func_array:{/var/www/html/web/core/lib/Drupal/Core/Form/FormSubmitter.php:114}()
FormSubmitter.php:114, Drupal\Core\Form\FormSubmitter->executeSubmitHandlers()
FormSubmitter.php:52, Drupal\Core\Form\FormSubmitter->doSubmitForm()
FormBuilder.php:597, Drupal\Core\Form\FormBuilder->processForm()
FormBuilder.php:325, Drupal\Core\Form\FormBuilder->buildForm()
FormController.php:73, Drupal\Core\Controller\FormController->getContentResult()
EarlyRenderingControllerWrapperSubscriber.php:123, call_user_func_array:{/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:123}()
EarlyRenderingControllerWrapperSubscriber.php:123, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure:/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:121-124}()
Renderer.php:583, Drupal\Core\Render\Renderer->executeInRenderContext()
EarlyRenderingControllerWrapperSubscriber.php:124, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
EarlyRenderingControllerWrapperSubscriber.php:97, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure:/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:96-98}()
HttpKernel.php:166, Symfony\Component\HttpKernel\HttpKernel->handleRaw()
HttpKernel.php:74, Symfony\Component\HttpKernel\HttpKernel->handle()
Session.php:58, Drupal\Core\StackMiddleware\Session->handle()
KernelPreHandle.php:48, Drupal\Core\StackMiddleware\KernelPreHandle->handle()
PageCache.php:106, Drupal\page_cache\StackMiddleware\PageCache->pass()
PageCache.php:85, Drupal\page_cache\StackMiddleware\PageCache->handle()
ReverseProxyMiddleware.php:48, Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
NegotiationMiddleware.php:51, Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
StackedHttpKernel.php:51, Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
DrupalKernel.php:704, Drupal\Core\DrupalKernel->handle()
index.php:19, {main}()

It seems that prior to 10.1 there was an issue with a block save causing a "double save", and a patch issued for it. It also seems that the issue went away in 10.1, but the patch was still being applied, and instead of stopping the second save from occurring, it stopped the only save from occurring.

@j. ayen green, thanks for reporting your findings.

Since this is not a bug in core I am changing to a support request.

I've done some playing with this as well based on @j. ayen green's findings.

The really perplexing thing is that, when running composer install with said patch, the command line reports:
Could not apply patch! Skipping.

However (at least some of) the code from the patch indeed is applied. And then, when removing the patch line from composer.json and running composer update or composer install, composer believes that the code does not need updating. It reports: Nothing to install, update or remove even though the (partially?) patched code persists. I have to manually rm -rf web/core after removing the patch line from composer.json, and then run composer install to get the correct version of the code in place.

I'm not clear on whether this is normal behavior for composer and cweagans/composer-patches, but it certainly seems odd, given that the terminal says that the patch was being skipped.

I'll look into raising this at cweagans/composer-patches, since I think that's the correct place to put the issue. But, I also wanted to notate it here in case anyone else comes across this. I'll also see if I can replicate this with a different patch.

@miwayha - Super find. Thank you for diving into it. It is perplexing, indeed. cweagans/composer-patches does seem like the home for this.

Automatically closed - issue fixed for 2 weeks with no activity.