LogicException: The database connection is not serializable.

I added a core issue that links to some others. In addition there have been reports of this being caused by some contributed modules.

Also: Please upgrade to 8.5.5 at your earliest convenience. We are not supporting 8.4.x releases at this time.

I get this exception in AJAX calls if I use object methods as callbacks, and don't get the exception if I use traditional callbacks.

If you are using the Locale module this may be relevant.

Try using the Drupal\Core\DependencyInjection\DependencySerializationTrait in your class, as it was done in #2893029: EntityType objects cannot be reliably serialized without DependencySerializationTrait.

#15 works for me on Drupal 9.3.5

Thanks

#15 works for me too.

The problem itself exists when you have more than 1 language installed and use the translation inside ajax form. The ajax form is cached and then the translated strings are serialized with everything that translation object has, including the locale lookup that has database connection as dependency.

I am also receiving the error when trying to upload images as part of a webform submission, this is only happening for anonymous users however and the images upload when I am logged in as admin.

LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution. in Drupal\Core\Database\Connection->__sleep() (line 1993 of /web/core/lib/Drupal/Core/Database/Connection.php).

I have tried the patch at #15 but this did not resolve my issue.

I have noticed a jquery error in the console when I try to upload images:

en/results/data-upload?element_parents=elements/collection/group_image&ajax_form=1&_wrapper_format=drupal_ajax 500 (500 Service unavailable (with message))

**edit**

The patch appears to have worked, there must have been a caching issue also.

Our website only has one language and is hit by this error. File upload forms stopped working and the website is essentially broken.

Patch #15 does not seem to work, even after clearing all caches.

Changing priority to major as this bug is breaking websites from being usable in some cases

EDIT: In our case, the issue is combination of this one + https://www.drupal.org/node/3279371

Can we get a test here - plus some steps to reproduce? I'm not sure that the explanation in #18 is correct. TranslatableMarkup don't serialise the stringTranslation property - see \Drupal\Core\StringTranslation\TranslatableMarkup::__sleep().

Patch #15 does not seem to work, even after clearing all caches.

In our case, deactivating honeypot for the form (in /admin/config/content/honeypot) solved the issue immediately.

Honeypot is causing a version of this.

FWIW: I ran into this issue and it turned out to be that Honeypot was enabled on all forms which is not best practice. Once I disabled that (or more to the point, had the editor role bypass honeypot) the issue went away without the patch. Something to look at if a certain role is having the issue.

EDIT: wow in the last couple of hours both pmunch and cilefen were able to capture this as well. Great minds I guess :)

I be am postponing this as it seems the causes may differ.

This has also plagued one of our projects (which has about 180 subsites, by the way).

We've implemented the patch in #15 and this seems to work!

The error occurred when attempting to open the media library from an "Add media" button on a block form.
This happened only with translations, the block form on the original node was fine.

I am getting this same error on D9.3.16 on my local dev and on my testing site.
But not on the production which is little bit behind with module and core versions.

It comes when saving a existing image style. (/admin/config/media/image-styles/manage/style-name/

None of these helped:

1. Uninstalled Honeypot (it was protecting only few forms) NO help
2. patched with #15 No help
3. restarted DB and APP servers and cleared cache with drush cr, No help
4. Tried to switch back to php 7.4 from 8.1 No help

The site seems weirdly slow also.

Error message is:
LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution. in Drupal\Core\Database\Connection->__sleep() (line 1993 of /var/www/html/site/web/core/lib/Drupal/Core/Database/Connection.php).

I will start to compare now the working production site to my local dev, what is different.

On Drupal 9.48 (to which I updated today from 9.35), this error seems to be gone.
I don't have to patch anymore (had used #15 sucsessfully on 9.35)

Got the same problem on a Drupal 9.5.9 / 9.5.10, migrated from a 8.x, when tring to add a file in a file field in a node.
No custom code in this content type.

Patch #15 works for me.
Thanks.

Five years later I come across this again, on Drupal 10.1.4. This time it happens if I set a translated error message in my form validation code. And does not happen with an untranslated error message. And the fix in #15 does seem to work.

Considering the nature of the exception and reading all the comments it seems likely that there are different causes for the exception, probably requiring different fixes.

I also wonder about the fix in #15, since the exception message states that DependencySerializationTrait should be looked as a temporary solution.

I'm seeing a similar issue on a Drupal 10.1.4 site, and I've narrowed it down to the Agreement module. Based on the comments that refer to the problem being with translating form errors, I think this code is the problem:

  public function validateForm(array &$form, FormStateInterface $form_state) {
    $storage = $form_state->getStorage();
    $agreement = $storage['agreement'];
    if (!$agreement->allowsRejecting() && !$form_state->getValue('agree') && !$storage['agreed']) {
      $settings = $agreement->getSettings();
      $form_state->setErrorByName('agree', $this->t('@agree_error', ['@agree_error' => $settings['failure']]));
    }
  }

If the form is getting serialized, and the error message is using t(), then it's possible this is where the database connection is getting serialized as well. I can't reproduce the issue locally, so I'm applying the patch in #15 and will verify when the change gets to production.

I am also curious about what should be done long-term if indeed DependencySerializationTrait is meant to be temporary.

Relating to a meta issue.

Adding the DependencySerializationTrait didn't seem to solve my issue, I either didn't put it in the right place, or it's not the same cause of the error. I'll keep looking and see if I can figure out where it's coming from.

Indeed, the problem is in an apparently unrelated class/object.

In #35, if you replace $this->t('@agree_error' with global t('@agree_error', I expect the problem to be gone.

Let me re-open this issue and post a proposal patch.
In the OP, I added some comments that makes the problem reproducable.
Please check #3400483: [meta] LogicException: The database connection is not serializable (for string translations in Ajax callback), which I created with many references to other reported issues of (apparently) the same problem.
IMO, adding DependencySerializationTrait to so many other, unrelated core/contrib classes is not the way to go. (Therefore, it is euphemistically a 'temporary' solution.)

Attached patch interferes in the serialization of the TranslationManager, which contains a list of Translators (TranslatorInterface).
By NOT serializing the listed Translators, the problem disappears.
Unlike other objects, those Translators are re-created after the unserialization of the form.

In my test case, 2 Translators were listed:
- Drupal\Core\StringTranslation\Translator\CustomStrings (serializable)
- Drupal\locale\LocaleTranslation (NOT serializable)
As per comments in other topics, the second is not serializable due to an open DatabaseConnection. The object contains DependencySerializationTrait itself, but apparently that does not work.

Hence, proposed solution is in TranslationManager, not in TranslatorInterface instances.
My test case: #3399054-23: Ajax error on [Add exception] button if "seasons" is activated

Let me first upload this patch, to check the tests.
Then, let me add another patch, removing DependencySerializationTrait from some core classes.

The Needs Review Queue Bot tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

I have the same issue in Drupal core 10.1.6 with nl translation node, confirm that #15 solves problems, it will be great to see that in core

@johnv I' ve tried the steps to reproduce and it does not happen for me with the address module. I've got a some questions about the steps to reproduce:

• Is it with the Standard install profile?
• What is the contrib field module you are using?
• Are there any other contrib modules installed?

@alexpott, please check attached patch for some test instructions.

Test by:
- Install with normal install profile.
- Enable locale module 'User interface translation' with +1 languages.
- Enable office_hours module and add field to a Content type.
- In Field settings, Allow both Exceptions and Seasons.
- Select widget type 'Office Hours (week) with exceptions and seasons'.
- Edit with non-English page, e.g., /nl/node/8/edit .
- Enable both Exceptions and Season in widget settings.
- Create/Edit node with non-English page, e.g., /nl/node/8/edit .
- Click 'Add Exception' button. (You may need to click twice.)
- Check if an empty exception is added, or error occurs.
Set breakpoint at OfficeHoursSeason~label() and OfficeHoursSeasonHeader~process().
@see https://www.drupal.org/project/office_hours/issues/3399054

You can provoke the error by switching between the following return values in OfficeHoursSeason~label():
- return $this->t($this->name);
- return t($this->name);
- return $this->name;
The first one will generate the error.

(IMO in previous Drupal versions, bootstrap::t() and $this->t() return different classes. I might be mistaken, because in my current D10.2 dev version, both return TranslatableMarkup, only created with different parameters. I never understood why there was/is a difference. )

@alexpott, please ignore the file in #43. It is too long. See newly attached file.

Having the same issue on 10.3.9, on image fields in my case.

I tried the patch from #39 but it doesn't apply:

sudo -u www-data patch -p1 < core_2987548-39_serialize.patch
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.

Tested.
Interestingly enough, the 3-year patch (#15) worked for Drupal11 (v 11.1.5)
#39 and #44 didn't apply.

This error is now gone and after patch #15 I can delete referenced entities without errors

LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution. in Drupal\Core\Database\Connection->__sleep() (line 1297 of /home/pearls/public_html/d11site/web/core/lib/Drupal/Core/Database/Connection.php)

@samlerner Did you ever get this figured out? I have the Agreement module installed also and have tried #15 with no success. #39 also gave me this when trying to apply:

sudo -u www-data patch -p1 < core_2987548-39_serialize.patch
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input. 

@hommesreponse I'm not entirely sure how, but the problem seems to be gone. I can't find those errors in our logs for the last 3 months, and I applied the patch in #15 back in 2023. We're on Drupal 10.4.6, maybe the problem was fixed elsewhere?

I'm still encountering the following error on the 11.x branch:

LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution. in Drupal\Core\Database\Connection->__sleep() (line 1309 of /var/www/html/core/lib/Drupal/Core/Database/Connection.php).

I've also re-rolled the patch from #15 to apply cleanly against the 11.x branch.

@rakesh.gectcr thanks you save my day.
I confirm patch #49 fixed this issue

@rakesh.gectcr, thanks for the patch. I can confirm that, patch #49 can fix this issue too.

I'm having the same problem on Drupal 11.2 and #49 solved it.

Anyway, the solution doesn't look definitive.

I've managed to reproduce this issue reliably with Drupal 11.2.0.

1. Install standard Drupal in French
2. Edit the admin/content view
3. Change a field name for example the actions field

You will get an ajax error and if you check the logs you will see:

 46   21/Jun 20:34   php      Erreur        LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database
                                             connection. Adjust your code s

Now that core itself can trigger this bug it is a critical.

We just need a test of serializing \Drupal\locale\LocaleTranslation ... will work on adding that.

Tagging because this now covers a regression in 11.2.0

I've added a test - well updated the existing \Drupal\Tests\locale\Kernel\LocaleTranslationTest::testSerializable() to test this problem. We're unlucky #3128389: LocaleTranslation is not serializable did not catch this.

The test now covers the bug - see https://git.drupalcode.org/issue/drupal-2987548/-/jobs/5632830

Test-only pipeline indeed throws the exception folks have been reporting all this time:

There was 1 error:
1) Drupal\Tests\locale\Kernel\LocaleTranslationTest::testSerializable
LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution.
/builds/issue/drupal-2987548/core/lib/Drupal/Core/Database/Connection.php:1309
/builds/issue/drupal-2987548/core/modules/locale/tests/src/Kernel/LocaleTranslationTest.php:49
ERRORS!

Crediting @alezu for #3531210: "The database connection is not serializable" error on views configuration save as this duplicate help find a way to reproduce this issue.

It's really great to have identified the actual root cause of this after so much time -- thanks @alexpott!

Could some of the folks encountering the latest version of this in production on 11.2.0 manually test and confirm that the above fixes the issue? If it's helpful, here's a patch version of the merge request:
https://git.drupalcode.org/project/drupal/-/merge_requests/12440.diff

Hiding outdated patch files for clarity.

Hi @xjm.

Like reported above, I had this error appearing and needed to patch with #49.

But now I have removed the patch and applied the MR!12440 and it works as expected.
I'm not having the error on the operations I was having before.

Thanks you @all for the effort is solving this.

OK great, thanks @jrochate for testing!

Ran test only to confirm and it fails with a relevant error.

Do core maintainers plan a D11.2.1 release in a near future?

@gillesbailleux yes we are planning to do a release once this makes it to 11.2.x and a couple of other critical regressions we've found.

Committed to 11.x and backported to 11.2.x

Thanks folks.

Given this is an old bug and can easily affect contrib and is not that often tested for (ie. test coverage of module not in the default language is probably pretty thing on the ground) - I think we should backport this fix to 10.5.x and 10.6.x

The cherry pick to 10.5.x is clean and the test passes.

Yeah makes sense to backport this one to 10.5.x too. Cherry-picked to both 10.x branches.

After upgrading to Drupal 11.2.0 Views returns the following error in the browser console:

"\nSi è verificato un errore HTTP in AJAX.\nCodice HTTP di risposta: 500\nDebugging information follows.\nPercorso: /admin/structure/views/ajax/display/tassonomia_ambito/block_1/title\nStatusText: error\nResponseText: The website encountered an unexpected error. Try again later."

Also, in the php logs I see this error:

LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution. in Drupal\Core\Database\Connection->__sleep() (line 1309 of /opt/drupal/web/core/lib/Drupal/Core/Database/Connection.php).

I have tested several patches, the #72 (https://git.drupalcode.org/project/drupal/-/merge_requests/12440.patch) works, views does not return any more error.

For some reason #78 made changes to the issue summary so I reverted it back to the state before that comment.