Redirect 404 decorates logger.factory and switches to it's own Redirect404LogSuppressor class which injects config factory which in turn injects storage which has a database connection.
When testing media_elvis module on a project I noticed that when the form get's rebuild I was getting
LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection
because this project users redirect 404 and we inject the logger.factory there.
Not sure if there is a better approach for this, but adding DependencySerializddationTrait to Redirect404LogSuppressor solves the issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | redirect-2860496-7-typo.patch | 621 bytes | gg4 |
| #4 | use-2860496-4.patch | 885 bytes | primsi |
| #2 | use-2860496-2.patch | 887 bytes | primsi |
Comments
Comment #2
primsi commentedInitial patch.
Comment #4
primsi commentedDoh, accidental vim delete line dd :|
Comment #6
berdirThanks.
Comment #7
gg4 commentedI think the latest patch is broken by a typo in the use statement for the trait.
Comment #8
gg4 commentedActually, the patch in https://www.drupal.org/node/2860496#comment-11985840 looks ok, but https://www.drupal.org/node/2860496#comment-11985807 is what was committed, which is not so much.
Comment #9
berdirDamn, thanks for catching that. Committed.
Comment #12
cburschkaThis suppressed the error, but introduced a different problem: As the inner objects _serviceId is still set to "logger.factory" (which is overridden), when the object is unserialized it actually gets itself as the inner loggerChannelFactory rather than the overridden core service.
Each time the object is serialized and unserialized, it adds another level to that chain, so you get $this->loggerChannelFactory->loggerChannelFactory->loggerChannelFactory->...
The underlying issue (both for this and for the original problem) is basically a core bug, namely that Drupal's dependency serialization can't handle decorated services: #2896993: Decorated services crash on serialization..
(I don't think this can be easily fixed by a change in this module, though, so it might be simplest to just keep the workaround as it is and hope that the object doesn't get serialized too often. As the decorator doesn't do anything beside suppressing log messages, it is idempotent. The chain should basically keep working until it is too big to cache, so it's not a critical problem.)