WSOD after upgrading 3.0.3 to 3.0.4: Unknown column 'node_field_data.deleted' in 'where clause'

(replaced \" with " in error message in issue summary)

This is not reproducing with the given steps on the Drupal 10.2.6 version.

Hmm... okay. I'll see if I can figure out some better steps to reproduce when I next have time.

For what it's worth, It took down my site and mangled my database - rolling back the code wasn't enough to fix the problem: I had to restore from yesterday's backup. For now I'm simply pinning trash to 3.0.3.

@mparker17, did you somehow run trash_post_update_set_enabled_entity_types_bundles() twice by any chance? That would be a situation where the enabled_entity_types property of trash.settings would become an empty array, and \Drupal\trash\EventSubscriber\TrashConfigSubscriber::onSave() would then remove the deleted field from all previously enabled entity types.

Maybe this additional check would help...

I figured out the problem: my deployment process was running database updates and then importing configuration immediately afterwards (i.e.: with drush deploy).

When I looked at the deployment logs, I saw it run the post_update hook (whose description said it was updating config), then I saw it re-importing trash config, and thought "🤔 the config import is probably stomping the config changes made in the post_update hook".

Anyway, I was able to fix it without need for the patch in #6 by...

1. Upgrading trash locally (composer update -w drupal/trash)
2. Running database updates (only!) locally (drush updatedb)
3. Exporting config (drush config:export)
4. Committing the changed config

... and after this, I can deploy to my shared environments normally (i.e.: they can run drush deploy, and because I committed the changed config, it works normally)

Thanks @amateescu! (and, thanks for your patience)

A longer description of what was happening is...

1. When I ran database updates, it would run trash_post_update_set_enabled_entity_types_bundles(), and that would make the following change to my trash.settings config object...
   

   diff --git a/config/common/trash.settings.yml b/config/common/trash.settings.yml
   index 0bd1d89441..2182920fbd 100644
   --- a/config/common/trash.settings.yml
   +++ b/config/common/trash.settings.yml
   @@ -1,8 +1,8 @@
    _core:
      default_config_hash: ....
    enabled_entity_types:
   -  - media
   -  - node
   +  media: {  }
   +  node: {  }
    auto_purge:
      enabled: false
      after: '30 days'
   

   ... but this config wasn't getting exported

2. Then, immediately after, my deploy process would import from the old configuration, reverting that change...
   

   diff --git a/config/common/trash.settings.yml b/config/common/trash.settings.yml
   index 0bd1d89441..2182920fbd 100644
   --- a/config/common/trash.settings.yml
   +++ b/config/common/trash.settings.yml
   @@ -1,8 +1,8 @@
    _core:
      default_config_hash: ....
    enabled_entity_types:
   -  media: {  }
   -  node: {  }
   +  - media
   +  - node
    auto_purge:
      enabled: false
      after: '30 days'
   

3. Then when I visited the site, the code would run, expecting enabled_entity_types to be string keys mapped to an arrays (because the update hook ran); and instead found numeric keys mapped to strings (because the config:import ran afterwards)

... so @amateescu's patch in #6 was definitely the right idea, but ultimately, it was my site config that was wrong.