🇨🇦Canada @jdhildeb

jdhildeb → created an issue.

This is my experience, too. Stay away from version 1.8. I upgraded to 1.8 on a site, worked through several issues including
* https://www.drupal.org/project/workflow/issues/3454189 🐛 hook_update_8003 to 8.x-1.8 installs optional config and breaks my site Active
* https://www.drupal.org/project/workflow/issues/3452716 🐛 Warning : Undefined array key "to_sid" in WorkflowTransitionElement::copyFormValuesToTransition() line 356 when using Ajax button from other field Fixed

I applied patches from the git repo, tested, had my users test, and thought I was good. But after deploying, my users are getting the "This value should not be null" error (possibly other edge cases of 3452716). And I discovered that handling of the "transition pre" is broken in 1.8. I will log this as a separate issue.

I appreciate the work of the developers and apologize for what may be seen as venting. And I know that they need more specifics in order to reproduce and fix the issues.

My purpose in adding to this issue is that Drupal users should see this info and avoid this version.

I hit this same issue.

I found that it is related to the "Column aggregation row applies to" setting within Format -> Settings.

If you set "Column aggregation row applies to" to "the page shown" then the error goes away. Switching it back to "the entire result set" causes the error to occur.

I hit this error in my development process working on a dev copy of a site.
It can be reproduced as follows:

1. Remove a field from your database (Drupal will rename the database table).
2. Export configuration.
3. Load a database snapshot from production (for example to debug a separate issue).
4. Import configuration.
5. Error occurs. In my case: Unexpected error during import with operation delete for field.storage.node.field_need_date_change: Exception thrown while performing a schema update. Cannot rename 'node__field_need_date_change' to 'field_deleted_data_f21a3876bc';: table 'field_deleted_data_f21a3876bc'; already exists.

The cause in my case was that I did not drop my existing database when loading the snapshot, I just simply loaded a mysqldump. This overwrites existing tables, but does not delete tables from your database which are not present in the new snapshot. So the previous copy of field_deleted_data_f21a3876bc from step 1 was still there in my local database, remained when loading the snapshot, and caused the error when I tried to import my configuration.

The workaround is to do drop database, create database before loading your snapshot, to clear out any unwanted tables like this.

jdhildeb → created an issue.

jdhildeb → created an issue.

Thank you, @alexandersluiter for this fix. I've applied your patch after encountering the broken cron job.

I'm updating the subject of this issue to make this patch easier to find.

jdhildeb → created an issue.

I have reproduced on a fresh drupal install, so hopefully someone with more knowledge of drupal filesystems can help investigate further.

Marking active and leaving as "major" because the only reasonable workaround is to upload files to public filesystem, which is not a good option if you are dealing with sensitive documents.

I am encountering this same issue. I am digging into it, and can reproduce it in my environment.

This is my analysis:
* I'm trying to upload a file into Drupal via the UI
* this causes FileSystem::prepareDirectory() to be called with $uri = 'private://2023-05'
* my private location is '/var/www/html/private-files' (which exists and is readable/writable by the PHP process)
* prepareDirectory() calls FileSystem::mkdir(), which calls FileSystem::mkdirCall() in the StreamWrapperManager::getScheme branch.
* mkdirCall calls back into FileSystem::mkdir()
* now mkdir() tries to create the directory recursively. In checking file_exists('/var'), it receives FALSE, even though /var exists and is readable by the PHP user.
* This is where I'm stuck - I don't know why file_exists is returning FALSE. I've tried calling clearstatcache just prior to the file_exists, but file_exists still returns FALSE. I've tried calling file_exists('/var') from a PHP script invoked using 'drush scr myscript.php' - it receives TRUE (and so does not reproduce the issue).
* Applying patch #6 fixes the issue for me. Drupal successfully creates private://2023-05 (aka /var/www/html/private-files/2023-05) and the upload succeeds. This is evidence that the issue is within Drupal and is not a result of an directory permission issue.

This is the stack trace at the point that file_exists('/var') returns FALSE:

┆ 6609 #0 /var/www/html/web/core/lib/Drupal/Core/StreamWrapper/LocalStream.php(346): Drupal\Core\File\FileSystem->mkdir()\n
┆ 6610 #1 [internal function]: Drupal\Core\StreamWrapper\LocalStream->mkdir()\n
┆ 6611 #2 /var/www/html/web/core/lib/Drupal/Core/File/FileSystem.php(255): mkdir()\n
┆ 6612 #3 /var/www/html/web/core/lib/Drupal/Core/File/FileSystem.php(188): Drupal\Core\File\FileSystem->mkdirCall()\n
┆ 6613 #4 /var/www/html/web/core/lib/Drupal/Core/File/FileSystem.php(538): Drupal\Core\File\FileSystem->mkdir()\n
┆ 6614 #5 /var/www/html/web/core/modules/file/file.module(1437): Drupal\Core\File\FileSystem->prepareDirectory()\n
┆ 6615 #6 /var/www/html/web/core/modules/file/src/Element/ManagedFile.php(76): file_managed_file_save_upload()\n
┆ 6616 #7 /var/www/html/web/core/modules/file/src/Plugin/Field/FieldWidget/FileWidget.php(329): Drupal\file\Element\ManagedFile::valueCallback()\n
┆ 6617 #8 [internal function]: Drupal\file\Plugin\Field\FieldWidget\FileWidget::value()\n
(I'm omitting the rest of the stack trace as the above is the relevant part).

I've updated the patch from #6 for compatibility with Drupal 9.5. It solves the first use case in the issue description.