This PR was merged into the 4.4 branch.
Discussion
----------
fix code style
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
I ran the CS fixer and checked all test methods to not make use of `void`.
Commits
-------
689e3039fc fix code style
This PR was merged into the 4.4 branch.
Discussion
----------
[Finder] actually compare the order of entries when any sorting is applied
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Without this change the tests where still passing if the sorting didn't work as expected. There are three more tests that sort by file times. I do not really know how to make them more stable though.
Commits
-------
f1ed653eee actually compare the order of entries when any sorting is applied
This PR was merged into the 4.4 branch.
Discussion
----------
[HttpKernel] harden test to not depend on the actual time
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
From time to time this test fails (e.g. https://travis-ci.com/github/symfony/symfony/jobs/468014427#L7092). We can fix that by not depending on the system clock which is actually not needed in this test.
Commits
-------
28a956baa9 harden test to not depend on the actual time
This PR was merged into the 4.4 branch.
Discussion
----------
[Form] disable error bubbling by default when inherit_data is configured
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#14441
| License | MIT
| Doc PR |
Commits
-------
8679c2ac05 disable error bubbling by default when inherit_data is configured
This PR was merged into the 4.4 branch.
Discussion
----------
[Yaml] do not dump extra trailing newlines for multiline blocks
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#38310
| License | MIT
| Doc PR |
Commits
-------
5fa9592d5e do not dump extra trailing newlines for multiline blocks
This PR was submitted for the 5.x branch but it was merged into the 4.4 branch instead.
Discussion
----------
Update README.md
update readme semver link to use https
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | no
| License | MIT
| Doc PR | no
I just update semver link to use https instead of http. 😉
Commits
-------
9ee2dc6d66 Update README.md
This PR was merged into the 4.4 branch.
Discussion
----------
[Messenger] Fix stopwach usage if it has been reset
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
I'm slowly migrating an application to messenger (from swarrot) and I
hit a strange bug. My message was well processeed **BUT** retry!
It comes from two things
* I manually reset the application (via the service resetter, to keep a
low memory usage)
* symfony/messenger try to collect some information, but since the
stopwatch has been reset, an exception occurs and the message has been
retried
So this patch avoid throwing an exception when everything works well
<details>
<summary>the trace:</summary>
```
18:45:41 INFO [messenger] Message AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage handled by AppBundle\Crawler\Messenger\MessageHandler\CrawlSitemapMessageHa
ndler::__invoke
[
"message" => AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage^ {
-crawlId: "885d23a7-8ad5-4935-a2b3-1c114ac76ded"
},
"class" => "AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage",
"handler" => "AppBundle\Crawler\Messenger\MessageHandler\CrawlSitemapMessageHandler::__invoke"
]
18:45:41 ERROR [messenger] Error thrown while handling message AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage. Sending for retry #1 using 1000 ms delay. Erro
r: "Event ""Symfony\Component\Messenger\Middleware\HandleMessageMiddleware" on "messenger.bus.default"" is not started."
[
"message" => AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage^ {
-crawlId: "885d23a7-8ad5-4935-a2b3-1c114ac76ded"
},
"class" => "AppBundle\Crawler\Messenger\Message\CrawlSitemapMessage",
"retryCount" => 1,
"delay" => 1000,
"error" => "Event ""Symfony\Component\Messenger\Middleware\HandleMessageMiddleware" on "messenger.bus.default"" is not started.",
"exception" => LogicException {
#message: "Event ""Symfony\Component\Messenger\Middleware\HandleMessageMiddleware" on "messenger.bus.default"" is not started."
#code: 0
#file: "./vendor/symfony/symfony/src/Symfony/Component/Stopwatch/Section.php"
#line: 142
trace: {
./vendor/symfony/symfony/src/Symfony/Component/Stopwatch/Section.php:142 { …}
./vendor/symfony/symfony/src/Symfony/Component/Stopwatch/Stopwatch.php:126 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/TraceableMiddleware.php:75 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/HandleMessageMiddleware.php:83 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/SendMessageMiddleware.php:74 { …}
./src/Middleware/ResetApplicationMiddlerwareMiddleware.php:14 {
AppBundle\Middleware\ResetApplicationMiddlerwareMiddleware->handle(Envelope $envelope, StackInterface $stack): Envelope^
› echo "couocu";
› return $stack->next()->handle($envelope, $stack);
› }
}
./vendor/symfony/symfony/src/Symfony/Bridge/Doctrine/Messenger/DoctrinePingConnectionMiddleware.php:34 { …}
./vendor/symfony/symfony/src/Symfony/Bridge/Doctrine/Messenger/AbstractDoctrineMiddleware.php:45 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/FailedMessageProcessingMiddleware.php:34 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/DispatchAfterCurrentBusMiddleware.php:68 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/RejectRedeliveredMessageMiddleware.php:48 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/AddBusNameStampMiddleware.php:37 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Middleware/TraceableMiddleware.php:43 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/MessageBus.php:80 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/TraceableMessageBus.php:41 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/RoutableMessageBus.php:54 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Worker.php:114 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Worker.php:77 { …}
./vendor/symfony/symfony/src/Symfony/Component/Messenger/Command/ConsumeMessagesCommand.php:198 { …}
./vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:255 { …}
./vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:989 { …}
./vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:96 { …}
./vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:290 { …}
./vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:82 { …}
./vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:166 { …}
./bin/console:29 { …}
}
}
]
```
</details>
Commits
-------
bf4b0cc022 [Messenger] Fix stopwach usage if it has been reset
This PR was merged into the 4.4 branch.
Discussion
----------
CS: Apply ternary_to_null_coalescing fixer
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
Since we don't need to support PHP 5 anymore, we can upgrade our older code to use the null coalescing operator and enforce its usage through our PHP CS Fixer configuration. I think, the usage of that operator improves the readability of our codebase at lot.
Note that the changes in this PR are (with the exception of `.php_cs.dist`) completely automated. You should get the same results by running the following command (and reverting the changes to PhpUnitBridge afterwards).
```sh
php-cs-fixer fix --rules='{"ternary_to_null_coalescing":true}' src
```
Commits
-------
07c4773d98 CS: Apply ternary_to_null_coalescing fixer
This PR was merged into the 4.4 branch.
Discussion
----------
[Mailer] Handle failure when sending DATA
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
When an exception is thrown while sending an email via SMTP (ie. A attachment is not readable) the SMTP connection is left opened with a partial message sent.
This PR closes the connection (we can't abort after sending the `DATA` command) in such situation.
/cc @fabpot
Commits
-------
849211a780 Handle failure when sending DATA
This PR was merged into the 4.4 branch.
Discussion
----------
[ProxyManagerBridge] fix PHP notice, switch to "friendsofphp/proxy-manager-lts"
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#39089
| License | MIT
| Doc PR | -
I submitted the fix for #39089 on the origin library at https://github.com/Ocramius/ProxyManager/pull/646.
Because of the [versioning policy](6d45615155/version-support.md (dependency-upgrades)) in use at the origin library, this fix won't be available for PHP < 7.4.
We usually resort to monkey-patching to workaround the policy and still ship the fix for 4.4 (which supports PHP >= 7.1).
This time, and as explained in https://github.com/Ocramius/ProxyManager/issues/630, I propose to delegate the fix to [friendsofphp/proxy-manager-lts](https://github.com/FriendsOfPHP/proxy-manager-lts/). It already embeds the fix and a few others that allow us to remove most of the monkey-patching we had to accumulate over time.
Commits
-------
389f5304c7 [ProxyManagerBridge] fix PHP notice, switch to "friendsofphp/proxy-manager-lts"
This PR was merged into the 4.4 branch.
Discussion
----------
[Intl] Update the ICU data to 68.2
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Commits
-------
4573965f74 [Intl] Update the ICU data to 68.2
This PR was merged into the 4.4 branch.
Discussion
----------
[Serializer] Fix DenormalizableInterface::denormalize() return type declaration in docblock
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N.A.
| License | MIT
| Doc PR | N.A.
DenormalizableInterface::denormalize() should not return anything, so the `@return` declaration should be removed. If you look at the usage in `CustomNormalizer::denormalize()`, it becomes clear that this method shouldn't return anything:
```php
public function denormalize($data, $type, $format = null, array $context = [])
{
$object = $this->extractObjectToPopulate($type, $context) ?: new $type();
$object->denormalize($this->serializer, $data, $format, $context);
return $object;
}
```
Commits
-------
00c90aed51 [Serializer] Fix DenormalizableInterface::denormalize() return type declaration in docblock
