Sounds like a "duplicate" of the two related issues.
I've given the MR here a round of testing in top of the 4.1.x branch in combination with the drd_agent 4.1x branch
Gathering patches for dependencies. This might take a minute.
- Upgrading drupal/drd_agent (4.1.2 => dev-4.1.x ab72fef): Checking out ab72fefab1 from cache
- Upgrading drupal/drd (4.1.6 => dev-4.1.x d6232f7): Checking out d6232f774f from cache
After applying the relevant db updates the connection between drd and drd_agent appear to be maintained as expected:
$ drush updb
----------- ----------- --------------- ---------------------------------------------------------------------------
Module Update ID Type Description
----------- ----------- --------------- ---------------------------------------------------------------------------
drd 8008 hook_update_n 8008 - Update crypt class names.
drd 8009 hook_update_n 8009 - Update crypt class names stored as keys in the cryptsetting field.
drd_agent 8002 hook_update_n 8002 - Update stored crypt methods after 4.1.3 update.
----------- ----------- --------------- ---------------------------------------------------------------------------
$ drush drd:ping
Executing Ping
==============
- on id 1: Drush Site-Install
-----------------------------
! [NOTE] drd_action_ping [drd_domain/1]: Success with response Drush Site-Install {"data":"pong"}
[OK] ok!
pong
[OK] Completed!
Looks like, somewhat similar to what is done in the drd_agent state and in drd_update_8008(), we need to update the relevant keys in the cryptsetting-field in the drd_domain table.
Some iteration on stored domains to update OpenSSL => OpenSsl.
I can have a closer look in the morning.
This issue appear to be caused by crypt method names stored in state not matching after 4.1.3.
jfauske → changed the visibility of the branch 3512611-openssl-not-found to hidden.
If the query parameters aren't there, then it's not possible to determine what the latest version of the aggregate might be. This was the original problem with pre-10.1.x versions of asset aggregation that this logic solved, the inability to regenerate an aggregate from a URL.
As @szeidler points out, the requests for "valid" js/css assets but with double encoded `&_` we see, are almost exclusively GPTBot.
This could likely be "works as designed"?
To me this just looks like a bit of a "naive" approach in web/core/modules/system/src/Controller/AssetControllerBase.php:deliver()
When receiving request, the (Js|Css)AssetController expects a js/css file to exist in the filesystem or that the request is "decorated" with some "special" query parameters.
So, if we get a "direct" request for an optimized js/css asset that is expired/removed, the controller will respond with a BadRequestHttpException.
You can reproduce this locally, or any up to date D10 site, by visiting any non-existent js/css urls like /sites/default/files/js/this-is-just-a-poc or /sites/default/files/css/this-is-just-a-poc
Likely these 400 errors are the result of "stale" caches and user agents just requesting asset urls no longer available from either a reverse proxy or Drupal (filesystem).
One might want to get a 301 redirect response from the relevant controller's deliver() to get the latest version of the optimized js/css instead, if one exists?
OK, I was wrong in my last assumption.
As already mentioned by @mondrake, the memory exhaustion issue we see, appear to be related to GD version bundled with PHP and can be resolved with building the GD extension using the "--with-external-gd" flag.
I.e on debian based something like this:
...
apt-get install ... libgd-dev ... \
&& docker-php-ext-configure gd --with-freetype --with-jpeg --with-webp --with-avif --with-external-gd
...
And on Alpine based:
...
apk add --no-cache ... gd-dev ... \
&& docker-php-ext-configure gd --with-freetype --with-jpeg --with-webp --with-avif --with-external-gd
...
I believe we are seeing some variation of this from time to time.
We are seeing it on images based on php:fpm-alpine, but unable to reproduce the issues in DDEV where the image is based on debian:slim.
Main difference there is Alpine use musl vs Debian is glibc.
Haven't had a chance to test yet, but I wonder if what we see can be related to what is discussed in https://github.com/php/php-src/issues/13877
Did you rebuild your caches after updating to 5.4.0?
Your error output indicate, to me, that you didn't.
Because Drupal\Core\Entity\EntityTypeBundleInfo implements Drupal\Core\Entity\EntityTypeBundleInfoInterface - which the fix imports.
And as such, the given Drupal\Core\Entity\EntityTypeBundleInfo object is of the required type... in 5.4.0.
I believe we only need to add the proper alias here as proposed in https://git.drupalcode.org/issue/webform_views-3467786/-/tree/3467786-fi...
Thanks a lot @andileco!
Can confim issue gone with 5.0.16 and 5.1.0 on 10.2.x and 10.3.x respectively.