…tations (sormes)

This PR was squashed before being merged into the 5.4 branch.

Discussion
----------

[Validator] Error using CssColor with doctrine annotations

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets       | none
| License       | MIT

When use doctrine annotations and set formats parameter throw and error

`array_merge(): Argument #2 must be of type array, null given`

`in vendor/symfony/validator/Constraints/CssColor.php (line 75) `

Commits
-------

bba6e15 [Validator] Error using CssColor with doctrine annotations

… resource (Seldaek)

This PR was squashed before being merged into the 4.4 branch.

Discussion
----------

[Process] Avoid calling fclose on an already closed resource

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #... <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->

I got this in Composer while interrupting an install process with Ctrl-C.

```
PHP Fatal error:  Uncaught TypeError: fclose(): supplied resource is not a valid stream resource in /var/www/composer/vendor/symfony/process/Pipes/AbstractPipes.php:50
Stack trace:
#0 /var/www/composer/vendor/symfony/process/Pipes/AbstractPipes.php(50): fclose()
#1 /var/www/composer/vendor/symfony/process/Pipes/UnixPipes.php(50): Symfony\Component\Process\Pipes\AbstractPipes->close()
#2 [internal function]: Symfony\Component\Process\Pipes\UnixPipes->__destruct()
#3 {main}
  thrown in /var/www/composer/vendor/symfony/process/Pipes/AbstractPipes.php on line 50
```

I am assuming it's due to a process which was not closed properly, which is very likely given we run a bunch of them concurrently.. It's pretty hard to debug as it's also hard to reproduce, so I am not sure what to do except handle this case gracefully in the close/__destruct function and hope that at least lets it clean up processes without crashing this way.

Commits
-------

a9e43a7 [Process] Avoid calling fclose on an already closed resource

…usse)

This PR was merged into the 4.4 branch.

Discussion
----------

[HttpClient] Handle requests with null body

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | /
| License       | MIT
| Doc PR        | /

since symfony#45527 passing null to the `body` parameters leads to an exception (which [breaks async-aws](https://github.com/async-aws/aws/blob/09723ddca29b8d1d522426f81dd422373de1785f/src/Core/src/AbstractApi.php#L157))

> Argument #2 ($body) must be of type Closure, null given, called in /home/runner/work/aws/aws/vendor/symfony/http-client/CurlHttpClient.php on line 221

In curl client: `null` is not a string and `self::readRequestBody` expects a closure.

https://github.com/symfony/symfony/blob/08fa74a16c84895575e305b2a7ee3a03e371f79b/src/Symfony/Component/HttpClient/CurlHttpClient.php#L214-L221

In NativeClient, `getBodyAsString` will fail to return `null` because of the `string` return type.

Before symfony#45527 null was converted to `""` thanks to the defaultOptions, but this is not the case anymore.

In many places, we check if the body is `!== ""` but rarely check if the body is null, this PR restores the original behaviors for the `body` parameters and converts nulls to `""`.

Commits
-------

39aec09 [HttpClient] Handle requests with null body

Because Security::LAST_USERNAME not always exist, it can trigger a "preg_match(): Argument #2 ($subject) must be of type string" if $username is null

…Security::LAST_USERNAME (David-Crty)

This PR was merged into the 5.4 branch.

Discussion
----------

[RateLimiter] Adding default empty string value on Security::LAST_USERNAME

Because `Security::LAST_USERNAME` not always exist, it can trigger a `preg_match(): Argument #2 ($subject) must be of type string` if $username is null

The error is critical when having `declare(strict_types=1)`, to avoid issue when people create their own LoginRateLimiter from the DefaultLoginRateLimiter we can juste set a default empty string.

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| License       | MIT

Commits
-------

0fdfcae [RateLimiter] Adding default empty value

In the cached file of my application I can see the following code fragment that have been generated by Symfony:
```php
if (( !((array_key_exists("render_preferred_choices", $context)) ? (_twig_default_filter((isset($context["render_preferred_choices"]) || array_key_exists("render_preferred_choices", $context) ? $context["render_preferred_choices"] : (function () { throw new RuntimeError('Variable "render_preferred_choices" does not exist.', 88, $this->source); })()), false)) : (false)) && Symfony\Bridge\Twig\Extension\twig_is_selected_choice($context["choice"], (isset($context["value"]) || array_key_exists("value", $context) ? $context["value"] : (function () { throw new RuntimeError('Variable "value" does not exist.', 88, $this->source); })())))) {
                    echo " selected=\"selected\"";
                }
```

The 2nd Arg passed when calling ``twig_is_selected_choice`` if the result of ``(isset($context["value"]) || array_key_exists("value", $context) ? $context["value"]``.

In that condition, if ``$context['value'] = null, we pass the null

Currently I got the following error:
```
Symfony\Bridge\Twig\Extension\twig_is_selected_choice(): Argument #2 ($selectedValue) must be of type array|string, null given, called in X:\workspace-novento\novento-vip-lounge\var\cache\admin_dev\twig\01\01615438ee40292438687b29025d08a9.php on line 534
```

…el057)

This PR was merged into the 6.0 branch.

Discussion
----------

Allow passing null in twig_is_selected_choice

| Q             | A
| ------------- | ---
| Branch?       | 6.0 and >
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| License       | MIT

In the cached file of my application, generated by Symfony I can see the following code fragment:
```php
if (( !((array_key_exists("render_preferred_choices", $context)) ? (_twig_default_filter((isset($context["render_preferred_choices"]) ||
array_key_exists("render_preferred_choices", $context) ? $context["render_preferred_choices"] : (function () { throw new
RuntimeError('Variable "render_preferred_choices" does not exist.', 88, $this->source); })()), false)) : (false)) && Symfony\Bridge
\Twig\Extension\twig_is_selected_choice($context["choice"], (isset($context["value"]) || array_key_exists("value", $context) ?
$context["value"] : (function () { throw new RuntimeError('Variable "value" does not exist.', 88, $this->source); })())))) {
                    echo " selected=\"selected\"";
                }
```

The 2nd Arg passed when calling ``twig_is_selected_choice`` is the result of ``(isset($context["value"]) || array_key_exists("value", $context) ? $context["value"]``. So in case ``$context['value'] = null``, we pass ``null`` as 2nd arg of ``twig_is_selected_choice``.

As a result in some case, when I submit form with empty (null) value, I got the following error:
```
Symfony\Bridge\Twig\Extension\twig_is_selected_choice(): Argument #2 ($selectedValue) must be of type array|string, null given, called in ...\var\cache\dev\twig\01\01615438ee40292438687b29025d08a9.php on line 534
```

Commits
-------

0186ecb Allow passing null in twig_is_selected_choice

…form field type inside array (l-naumann)

This PR was squashed before being merged into the 6.4 branch.

Discussion
----------

[Mime] Throw InvalidArgumentException on invalid form field type inside array

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Tickets       | n/a
| License       | MIT

Example code:
```php
$f = new FormDataPart([
            'foo' => [
                'bar' => 'baz',
                'qux' => [
                    'quux' => 1,
                ],
            ],
        ]);
$f->getParts();
```

Currently, when you use a disallowed type inside an array, a TypeError is thrown:
` Symfony\Component\Mime\Part\Multipart\FormDataPart::configurePart(): Argument #2 ($part) must be of type Symfony\Component\Mime\Part\TextPart, int given`

This change adds a clearly understandable error message:
`The value of the form field "foo[qux][quux]" can only be a string, an array, or an instance of TextPart ("int" given).`

Commits
-------

08f5d7c [Mime] Throw InvalidArgumentException on invalid form field type inside array

This PR was merged into the 5.4 branch.

Discussion
----------

[Process] Fixed inconsistent test

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | N/A
| License       | MIT

Sometimes the process no longer appears to be running when the signal is sent which causes a LogicException to be thrown. This doesn't appear to be consistent and I can reproduce it randomly on my local machine. To avoid having tests fail at random I decided that it's better to send the signal only if the process is still marked as running.

```bash
amne@wnbpowerbox:~/work/projects/symfony$ php7.4 src/Symfony/Component/Process/Tests/ErrorProcessInitiator.php
The process "'php' '-r' 'echo '\''ready'\''; trigger_error('\''error'\'', E_USER_ERROR);'" exceeded the timeout of 0.5 seconds.
amne@wnbpowerbox:~/work/projects/symfony$ php7.4 src/Symfony/Component/Process/Tests/ErrorProcessInitiator.php
The process "'php' '-r' 'echo '\''ready'\''; trigger_error('\''error'\'', E_USER_ERROR);'" exceeded the timeout of 0.5 seconds.
amne@wnbpowerbox:~/work/projects/symfony$ php7.4 src/Symfony/Component/Process/Tests/ErrorProcessInitiator.php
The process "'php' '-r' 'echo '\''ready'\''; trigger_error('\''error'\'', E_USER_ERROR);'" exceeded the timeout of 0.5 seconds.
amne@wnbpowerbox:~/work/projects/symfony$ php7.4 src/Symfony/Component/Process/Tests/ErrorProcessInitiator.php
The process "'php' '-r' 'echo '\''ready'\''; trigger_error('\''error'\'', E_USER_ERROR);'" exceeded the timeout of 0.5 seconds.
amne@wnbpowerbox:~/work/projects/symfony$ php7.4 src/Symfony/Component/Process/Tests/ErrorProcessInitiator.php
PHP Fatal error:  Uncaught Symfony\Component\Process\Exception\LogicException: Cannot send signal on a non running process. in /home/amne/work/projects/symfony/src/Symfony/Component/Process/Process.php:1502
Stack trace:
#0 /home/amne/work/projects/symfony/src/Symfony/Component/Process/Process.php(516): Symfony\Component\Process\Process->doSignal()
#1 /home/amne/work/projects/symfony/src/Symfony/Component/Process/Tests/ErrorProcessInitiator.php(28): Symfony\Component\Process\Process->signal()
#2 {main}
  thrown in /home/amne/work/projects/symfony/src/Symfony/Component/Process/Process.php on line 1502
```

Commits
-------

00ee4ca [Process] Fixed inconsistent test

…read from socket (xdanik)

This PR was merged into the 5.4 branch.

Discussion
----------

[Mailer] Throw `TransportException` when unable to read from socket

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? |no
| Issues        | None
| License       | MIT

We are seeing error `fgets(): SSL: Connection reset by peer` multiple times a day from connection to Office 365 SMTP server (smtp.office365.com:587).
It's certainly related to some kind of timeout as we are sending emails from long running queue dispatcher and error shows up only occasionally and never with the first message. We are not seeing this issue with any other SMTP server, but we have not tested much past smtp.mandrillapp.com and local MailHog.

We have tried adjusting the `$pingThreshold` and `$restartThreshold` options, but without much success (well `$restartThreshold = 1` resolves the issue, but it also forces the transport to close connection after each message).

Stack trace:
```
#0 /var/www/vendor/symfony/mailer/Transport/Smtp/Stream/AbstractStream.php(77): fgets(Resource(stream))
#1 /var/www/vendor/symfony/mailer/Transport/Smtp/SmtpTransport.php(315): Symfony\Component\Mailer\Transport\Smtp\Stream\AbstractStream->readLine()
#2 /var/www/vendor/symfony/mailer/Transport/Smtp/SmtpTransport.php(181): Symfony\Component\Mailer\Transport\Smtp\SmtpTransport->getFullResponse()
#3 /var/www/vendor/symfony/mailer/Transport/Smtp/SmtpTransport.php(140): Symfony\Component\Mailer\Transport\Smtp\SmtpTransport->executeCommand("RSET
", Array(1))
#4 /var/www/vendor/symfony/mailer/Mailer.php(45): Symfony\Component\Mailer\Transport\Smtp\SmtpTransport->send(Object(Symfony\Component\Mime\Email), Null)
#5 (our queue dispatcher): Symfony\Component\Mailer\Mailer->send(Object(Symfony\Component\Mime\Email))
```

App is running on PHP 8.0.28 on Debian Linux x64, Mailer v5.4.22.

I would gladly written some tests for this, but I don't know how to simulate calls to low-level stream functions like fgets.

Commits
-------

44d5b57 [Mailer] Throw TransportException when unable to read from socket

…hen publishing a message. (jwage)

This PR was squashed before being merged into the 6.4 branch.

Discussion
----------

[Messenger] [Amqp] Handle AMQPConnectionException when publishing a message.

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | Fix symfony#36538 Fix symfony#48241
| License       | MIT

If you have a message handler that dispatches messages to another queue, you can encounter `AMQPConnectionException` with the message "Library error: a SSL error occurred" or "a socket error occurred"  depending on if you are using tls or not or if you are running behind a load balancer or not.

You can manually reproduce this issue by dispatching a message where the handler then dispatches another message to a different queue, then go to rabbitmq admin and close the connection manually, then dispatch another message and when the message handler goes to dispatch the other message, you will get this exception:

```
a socket error occurred
#0 /vagrant/vendor/symfony/amqp-messenger/Transport/AmqpTransport.php(60): Symfony\Component\Messenger\Bridge\Amqp\Transport\AmqpSender->send()
#1 /vagrant/vendor/symfony/messenger/Middleware/SendMessageMiddleware.php(62): Symfony\Component\Messenger\Bridge\Amqp\Transport\AmqpTransport->send()
#2 /vagrant/vendor/symfony/messenger/Middleware/FailedMessageProcessingMiddleware.php(34): Symfony\Component\Messenger\Middleware\SendMessageMiddleware->handle()
#3 /vagrant/vendor/symfony/messenger/Middleware/DispatchAfterCurrentBusMiddleware.php(61): Symfony\Component\Messenger\Middleware\FailedMessageProcessingMiddleware->handle()
#4 /vagrant/vendor/symfony/messenger/Middleware/RejectRedeliveredMessageMiddleware.php(41): Symfony\Component\Messenger\Middleware\DispatchAfterCurrentBusMiddleware->handle()
#5 /vagrant/vendor/symfony/messenger/Middleware/AddBusNameStampMiddleware.php(37): Symfony\Component\Messenger\Middleware\RejectRedeliveredMessageMiddleware->handle()
#6 /vagrant/vendor/symfony/messenger/Middleware/TraceableMiddleware.php(40): Symfony\Component\Messenger\Middleware\AddBusNameStampMiddleware->handle()
#7 /vagrant/vendor/symfony/messenger/MessageBus.php(70): Symfony\Component\Messenger\Middleware\TraceableMiddleware->handle()
#8 /vagrant/vendor/symfony/messenger/TraceableMessageBus.php(38): Symfony\Component\Messenger\MessageBus->dispatch()
#9 /vagrant/src/Messenger/MessageBus.php(37): Symfony\Component\Messenger\TraceableMessageBus->dispatch()
#10 /vagrant/vendor/symfony/mailer/Mailer.php(66): App\Messenger\MessageBus->dispatch()
symfony#11 /vagrant/src/Mailer/Mailer.php(83): Symfony\Component\Mailer\Mailer->send()
symfony#12 /vagrant/src/Mailer/Mailer.php(96): App\Mailer\Mailer->send()
symfony#13 /vagrant/src/MessageHandler/Trading/StrategySubscriptionMessageHandler.php(118): App\Mailer\Mailer->sendEmail()
symfony#14 /vagrant/src/MessageHandler/Trading/StrategySubscriptionMessageHandler.php(72): App\MessageHandler\Trading\StrategySubscriptionMessageHandler->handle()
symfony#15 /vagrant/vendor/symfony/messenger/Middleware/HandleMessageMiddleware.php(152): App\MessageHandler\Trading\StrategySubscriptionMessageHandler->__invoke()
symfony#16 /vagrant/vendor/symfony/messenger/Middleware/HandleMessageMiddleware.php(91): Symfony\Component\Messenger\Middleware\HandleMessageMiddleware->callHandler()
symfony#17 /vagrant/vendor/symfony/messenger/Middleware/SendMessageMiddleware.php(71): Symfony\Component\Messenger\Middleware\HandleMessageMiddleware->handle()
symfony#18 /vagrant/vendor/symfony/messenger/Middleware/FailedMessageProcessingMiddleware.php(34): Symfony\Component\Messenger\Middleware\SendMessageMiddleware->handle()
symfony#19 /vagrant/vendor/symfony/messenger/Middleware/DispatchAfterCurrentBusMiddleware.php(68): Symfony\Component\Messenger\Middleware\FailedMessageProcessingMiddleware->handle()
symfony#20 /vagrant/vendor/symfony/messenger/Middleware/RejectRedeliveredMessageMiddleware.php(41): Symfony\Component\Messenger\Middleware\DispatchAfterCurrentBusMiddleware->handle()
symfony#21 /vagrant/vendor/symfony/messenger/Middleware/AddBusNameStampMiddleware.php(37): Symfony\Component\Messenger\Middleware\RejectRedeliveredMessageMiddleware->handle()
symfony#22 /vagrant/vendor/symfony/messenger/Middleware/TraceableMiddleware.php(40): Symfony\Component\Messenger\Middleware\AddBusNameStampMiddleware->handle()
symfony#23 /vagrant/vendor/symfony/messenger/MessageBus.php(70): Symfony\Component\Messenger\Middleware\TraceableMiddleware->handle()
symfony#24 /vagrant/vendor/symfony/messenger/TraceableMessageBus.php(38): Symfony\Component\Messenger\MessageBus->dispatch()
symfony#25 /vagrant/vendor/symfony/messenger/RoutableMessageBus.php(54): Symfony\Component\Messenger\TraceableMessageBus->dispatch()
symfony#26 /vagrant/vendor/symfony/messenger/Worker.php(162): Symfony\Component\Messenger\RoutableMessageBus->dispatch()
symfony#27 /vagrant/vendor/symfony/messenger/Worker.php(109): Symfony\Component\Messenger\Worker->handleMessage()
symfony#28 /vagrant/vendor/symfony/messenger/Command/ConsumeMessagesCommand.php(238): Symfony\Component\Messenger\Worker->run()
symfony#29 /vagrant/vendor/symfony/console/Command/Command.php(326): Symfony\Component\Messenger\Command\ConsumeMessagesCommand->execute()
symfony#30 /vagrant/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
symfony#31 /vagrant/vendor/symfony/framework-bundle/Console/Application.php(126): Symfony\Component\Console\Application->doRunCommand()
symfony#32 /vagrant/vendor/symfony/console/Application.php(324): Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand()
symfony#33 /vagrant/vendor/symfony/framework-bundle/Console/Application.php(80): Symfony\Component\Console\Application->doRun()
symfony#34 /vagrant/vendor/symfony/console/Application.php(175): Symfony\Bundle\FrameworkBundle\Console\Application->doRun()
symfony#35 /vagrant/vendor/symfony/runtime/Runner/Symfony/ConsoleApplicationRunner.php(49): Symfony\Component\Console\Application->run()
symfony#36 /vagrant/vendor/autoload_runtime.php(29): Symfony\Component\Runtime\Runner\Symfony\ConsoleApplicationRunner->run()
symfony#37 /vagrant/bin/console(11): require_once('...')
symfony#38 {main}
```

TODO:

- [x] Add test for retry logic when publishing messages

Commits
-------

f123370 [Messenger] [Amqp] Handle AMQPConnectionException when publishing a message.

…cing keys (Brajk19)

This PR was squashed before being merged into the 6.4 branch.

Discussion
----------

[Validator] UniqueValidator - normalize before reducing keys

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        |
| License       | MIT

In symfony#42403 checking for uniqueness of certain collection keys was enabled. Method `UniqueValidator::reduceElementKeys` removes all keys which are not specified.
Problem is that this happens before normalization, which in my opinion is not great because that method accepts array argument and if i have some object (DTO), TypeError will be thrown.

Example:

```php
class ParentDTO
{
    /**
     * `@var` ChildDTO[]
     */
    #[Assert\Unique(
        normalizer: [ChildDTO::class, 'normalize']
        fields: 'id'
    )]
    public array $children;
}
```

```php
class ChildDTO
{
    public string $id;
    public string $name;

    public static function normalize(self $obj): array
    {
        return [
            'id' => $obj->id,
            'name' => $obj->name
        ];
    }
}
```

Because normalization will happen after `reduceElementKeys` this will be thrown:
`TypeError: Symfony\Component\Validator\Constraints\UniqueValidator::reduceElementKeys(): Argument #2 ($element) must be of type array, ...\ChildDTO given, called in .../UniqueValidator.php on line 48`

If `$element = $normalizer($element);` is executed before `reduceElementKeys` it would enable using Assert\Unique with array of objects when correctly normalized

Commits
-------

77df90b [Validator] UniqueValidator - normalize before reducing keys

…s string similar to username/password (glaubinix)

This PR was squashed before being merged into the 5.4 branch.

Discussion
----------

[Security] Validate that CSRF token in form login is string similar to username/password

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | See exception output below
| License       | MIT

<!--
Replace this notice by a description of your feature/bugfix.
This will help reviewers and should be a good start for the documentation.

 - Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
 - Never break backward compatibility (see https://symfony.com/bc).
-->

Fixes
```
Uncaught Error: Symfony\Component\Security\Http\Authenticator\Passport\Badge\CsrfTokenBadge::__construct(): Argument #2 ($csrfToken) must be of type ?string, array given, called in /vendor/symfony/security-http/Authenticator/FormLoginAuthenticator.php on line 88
```

Commits
-------

b501bba [Security] Validate that CSRF token in form login is string similar to username/password

…alexandre-daubois)

This PR was merged into the 5.4 branch.

Discussion
----------

[HttpClient] Fix cURL default options for PHP 8.4

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | -
| License       | MIT

PHP 8.4 brings a change in ext/curl (php/php-src#13291) that requires `CurlResponse` to be updated. Curl callbacks cannot be set to null anymore and requires real callable.

Here is (one of) the CI error it fixes:

```
10) Symfony\Component\HttpClient\Tests\CurlHttpClientTest::testGzipBroken
Failed asserting that exception of type "TypeError" matches expected exception "Symfony\Contracts\HttpClient\Exception\TransportExceptionInterface". Message was: "curl_setopt_array(): Argument #2 ($options) must be a valid callback for option CURLOPT_PROGRESSFUNCTION, no array or string given" at
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Response/CurlResponse.php:175
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Internal/Canary.php:32
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Response/TransportResponseTrait.php:90
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Response/TransportResponseTrait.php:218
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Response/CommonResponseTrait.php:68
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Response/CurlResponse.php:232
/home/runner/work/symfony/symfony/src/Symfony/Contracts/HttpClient/Test/HttpClientTestCase.php:1113
```

Commits
-------

cc0b957 [HttpClient] Fix cURL default options

…rsimpsons)

This PR was merged into the 5.4 branch.

Discussion
----------

[Yaml] 🐛 throw ParseException on invalid date

| Q             | A
| ------------- | ---
| Branch?       | 5.4 <!-- see below -->
| Bug fix?      | yes
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Issues        | None <!-- prefix each issue number with "Fix #", no need to create an issue if none exists, explain below instead -->
| License       | MIT

(found in symfony-tools/docs-builder#179)

When parsing the following yaml:
```
date: 6418-75-51
```

`symfony/yaml` will throw an exception:
```
$ php main.php
PHP Fatal error:  Uncaught Exception: Failed to parse time string (6418-75-51) at position 6 (5): Unexpected character in /tmp/symfony-yaml/vendor/symfony/yaml/Inline.php:714
Stack trace:
#0 /tmp/symfony-yaml/vendor/symfony/yaml/Inline.php(714): DateTimeImmutable->__construct()
#1 /tmp/symfony-yaml/vendor/symfony/yaml/Inline.php(312): Symfony\Component\Yaml\Inline::evaluateScalar()
#2 /tmp/symfony-yaml/vendor/symfony/yaml/Inline.php(80): Symfony\Component\Yaml\Inline::parseScalar()
#3 /tmp/symfony-yaml/vendor/symfony/yaml/Parser.php(790): Symfony\Component\Yaml\Inline::parse()
#4 /tmp/symfony-yaml/vendor/symfony/yaml/Parser.php(341): Symfony\Component\Yaml\Parser->parseValue()
#5 /tmp/symfony-yaml/vendor/symfony/yaml/Parser.php(86): Symfony\Component\Yaml\Parser->doParse()
#6 /tmp/symfony-yaml/vendor/symfony/yaml/Yaml.php(77): Symfony\Component\Yaml\Parser->parse()
#7 /tmp/symfony-yaml/main.php(8): Symfony\Component\Yaml\Yaml::parse()
#8 {main}
  thrown in /tmp/symfony-yaml/vendor/symfony/yaml/Inline.php on line 714
```

This is because the "month" is invalid. Fixing the "month" will trigger about the same issue because the "day" would be invalid.

With the current change it will throw a `ParseException`.

Commits
-------

6d71a7e 🐛 throw ParseException on invalid date

…h()` (simoheinonen)

This PR was merged into the 5.4 branch.

Discussion
----------

[MonologBridge] Fix PHP deprecation with `preg_match()`

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        |
| License       | MIT

```
preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated
```

Commits
-------

4d7a6f6 Passing null to parameter #2 ($subject) of type string is deprecated

* 5.4:
  do not mix named and positional arguments in data provider definitions
  session names must not be empty
  fix Contracts directory name in PHPUnit configuration
  Passing null to parameter #2 ($subject) of type string is deprecated

* 6.4:
  do not mix named and positional arguments in data provider definitions
  session names must not be empty
  fix Contracts directory name in PHPUnit configuration
  Passing null to parameter #2 ($subject) of type string is deprecated

* 7.1:
  do not mix named and positional arguments in data provider definitions
  session names must not be empty
  add missing properties
  fix Contracts directory name in PHPUnit configuration
  [Validator][CidrValidator] Fix error message for `OutOfRangeNetmask` validation
  Passing null to parameter #2 ($subject) of type string is deprecated

… not throw exception (lyrixx)

This PR was merged into the 5.4 branch.

Discussion
----------

[HttpKernel] Ensure `HttpCache::getTraceKey()` does not throw exception

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | -
| License       | MIT

We have such logs in our logs. It's in our raw PHP logs. They are not caught by monolog, it's too early

```
[11-Oct-2024 01:23:33 UTC] PHP Fatal error:  Uncaught Symfony\Component\HttpFoundation\Exception\SuspiciousOperationException: Invalid method override "__CONSTRUCT". in /var/www/redirection.io/backend/blue/vendor/symfony/http-foundation/Request.php:1234
Stack trace:
#0 /var/www/redirection.io/backend/blue/vendor/symfony/http-kernel/HttpCache/HttpCache.php(728): Symfony\Component\HttpFoundation\Request->getMethod()
#1 /var/www/redirection.io/backend/blue/vendor/symfony/http-kernel/HttpCache/HttpCache.php(207): Symfony\Component\HttpKernel\HttpCache\HttpCache->getTraceKey()
#2 /var/www/redirection.io/backend/blue/vendor/symfony/http-kernel/Kernel.php(188): Symfony\Component\HttpKernel\HttpCache\HttpCache->handle()
#3 /var/www/redirection.io/backend/blue/web/app.php(9): Symfony\Component\HttpKernel\Kernel->handle()
#4 {main}
  thrown in /var/www/redirection.io/backend/blue/vendor/symfony/http-foundation/Request.php on line 1234

```

I managed to reproduced locally.
* Before the patch, without the http_cache, symfony returns a 405
* After the patch, without the http_cache, symfony returns a 405
* Before the patch, with the http_cache, symfony returns a 500, without any information (too early)
* After the patch, with the http_cache, symfony returns a 405

Commits
-------

a2ebbe0 [HttpKernel] Ensure HttpCache::getTraceKey() does not throw exception