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
This PR was merged into the 4.4 branch.
Discussion
----------
Remove :void in test function signatures
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | n/a<!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
| Doc PR | n/a
I've added a new rule in fabbot to detect usage of `: void` in test method signatures to please @nicolas-grekas :)
Commits
-------
47fcf4ad5a Remove :void in test function signatures
This PR was merged into the 4.4 branch.
Discussion
----------
Remove void return type from test methods
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | ---
| License | MIT
| Doc PR | ---
cc @nicolas-grekas
Commits
-------
f126cf1304 Remove void return type from test methods
This PR was merged into the 4.4 branch.
Discussion
----------
Normalize exceptions messages containing methods references
| Q | A
| ------------- | ---
| Branch? | 4.4 <!-- see below -->
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix https://github.com/symfony/symfony/pull/39399#discussion_r544972437 <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
| Doc PR | N/A
Normalizes across the codebase any exception message mentioning methods to contain a trailing `()`
(Seems OK on 5.1 and 5.2 branch after this on is merged up)
Commits
-------
e2da2acd6d Normalize exceptions messages containing methods references
This PR was submitted for the 5.x branch but it was merged into the 4.4 branch instead.
Discussion
----------
Basque translations
Fix#38726
Commits
-------
37a8e79650 Added basque translations
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Mailer] Fix parsing Dsn with empty user/password
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | no
| License | MIT
| Doc PR | no
While working on a PR for Notifier that user and password would be parsed as an empty string, which is not wrong, but not expected IMO. Thi
`scheme://@symfony.com` and `scheme://:@symfony.com` should be a valid scheme with user and pass `null`
Another fix would be to check for `://@` and `://:@` and throw an `InvalidArgumentException` WDYT?
The final solution will then be applied to the Notifier DSN in `5.1`
Commits
-------
041cb46e52 [Mailer] Fix parsing Dsn with empty user/password
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Ldap] Incorrect determination of RelativeDistinguishedName for the "move" operation
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
If the specified "DistinguishedName" contains a comma in the first value, the first "RelativeDistinguishedName" was determined incorrectly.
The regular expression now matches up to the first comma which was not escaped with backslash.
Testing private methods is a bit messy here. However, I thought it was better than testing this against an LDAP server.
Source: https://tools.ietf.org/html/rfc4514#section-3
Commits
-------
c7e99a2523 [Ldap] Incorrect determination of RelativeDistinguishedName for the "move" operation
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Mailer] [Amazon] Ensure "ext-simplexml" is loaded if SesApiTransport is used
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | ---
| License | MIT
| Doc PR | ---
For reference:
150d8506e4/src/Symfony/Component/Mailer/Bridge/Amazon/Transport/SesApiTransport.php (L66-L69)
Commits
-------
a40d1375f9 [Mailer] [Amazon] Ensure "ext-simplexml" is loaded if SesApiTransport is used
This PR was merged into the 4.4 branch.
Discussion
----------
[PhpUnitBridge] [phpunit] Stop using deprecated trait
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
the `SetUpTearDownTrait` trait has been removed in #39487 this PR remove usage of it in branch 4.4
Commits
-------
55ed00cd3c Stop using deprecated trait
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[PhpUnitBridge] Lint files with PHP 5.5
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
I'd like to make sure that PhpUnitBridge remains compatible with PHP 5.5.
cc @nicolas-grekas @fancyweb
Commits
-------
0bc15ff759 [PhpUnitBridge] Lint files with PHP 5.5
This PR was merged into the 4.4 branch.
Discussion
----------
[Serializer] Fix EncoderInterface::encode() return type
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N.A.
| License | MIT
| Doc PR | N.A.
I might have missed something (in that case, please let me know), but I believe that `EncoderInterface::encode()` will and should always return a `string`. This makes more sense because `DecoderInterface::decode()` only accepts a string as input.
Commits
-------
ae6f054cc1 Fix EncoderInterface::encode() return type
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Lock] Prevent store exception break combined store
| Q | A
| ------------- | ---
| Branch? | 4.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 | Fix#39470 <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
Handle exception to preserve expected behavior - one or multiple stores could be unreachable in a moment and combined store will handle this according to strategy.
Commits
-------
0daff35bae [Lock] Prevent store exception break combined store
