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
* 5.2:
[FrameworkBundle][RateLimiter] Update typos in config
Handle ValueErrors triggered by ext-uuid on PHP 8
Add test case to ensure all security events are propagated
This PR was merged into the 5.1 branch.
Discussion
----------
[Uid] Handle ValueErrors triggered by ext-uuid on PHP 8
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
Follows symfony/polyfill#318.
On PHP 8, the UUID extension triggers `ValueErrors` if we pass an invalid UUID to one of the `uuid_*` functions. This PR handles those errors so that the component behaves the same on PHP 7 and 8.
Commits
-------
5305170e54 Handle ValueErrors triggered by ext-uuid on PHP 8
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Notifier] [Slack] Validate token syntax
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | ---
| License | MIT
| Doc PR | -
This PR follows https://github.com/symfony/symfony/issues/39560
@odolbeau @malteschlueter @norkunas @fabpot can you confirm all your tokens start with `xox`?
_From the Slack documentation:_
* Bot user token strings begin with `xoxb-`
* User token strings begin with `xoxp-`
* Workspace access token strings begin with `xoxa-2`
Commits
-------
59f29c592b [Notifier] [Slack] Validate token syntax
This PR was squashed before being merged into the 5.2 branch.
Discussion
----------
[FrameworkBundle][RateLimiter] Update typos in config
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
This is just a super minor
Commits
-------
1b4ab3e3a2 [FrameworkBundle][RateLimiter] Update typos in config
This PR was merged into the 5.1 branch.
Discussion
----------
[Security] Add test to ensure all security events are propagated
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| License | MIT
Follow-up to #39621. As requested by @wouterj I'm adding a dedicated test case to ensure the security events are propagated from global to firewall-level event dispatcher.
I'll file another PR to add `AuthenticationTokenCreatedEvent` as soon as this has been merged and copied to the 5.2 branch, that I need to target for the `AuthenticationTokenCreatedEvent` change.
Happy holidays!
Commits
-------
e78adf7604 Add test case to ensure all security events are propagated
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 squashed before being merged into the 5.1 branch.
Discussion
----------
[Security] Fix event propagation for globally registered security events
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| License | MIT
When new authenticator security is enabled, the `AuthenticatorManager` is using its own firewall-specific event dispatcher. To allow security events being listened to on the global level, `RegisterGlobalSecurityEventListenersPass` is there to automatically add globally registered event listeners to the firewall-specific event dispatchers.
`RegisterGlobalSecurityEventListenersPass` contains a list of events that are propagated, but unfortunately this list is incomplete as there are other events in `AuthenticatorManager` that would need too be propagated. So I added the missing (older) security events. These older events may also be registered by their name, rather than the FQN of the class, so I've also added those.
As this is targeting 5.1, I'll file another PR for the `AuthenticationTokenCreatedEvent` that was introduced in 5.2, as soon as this change was merged into 5.x.
On a note, I feel this "whitelist" approach to propagate security events to the global dispatcher isn't that great, because it's prone to error. Additional security events may be added in the future and adding these to `RegisterGlobalSecurityEventListenersPass` can easily be missed. When I added `AuthenticationTokenCreatedEvent` in PR #37359 I wasn't aware of this propagation mechanic existed and also no one reviewing the PR noticed it.
Additional changes:
- Typo fix :)
- The `array_uintersect` in `RegisterGlobalSecurityEventListenersPassTest` wasn't implemented correctly *
\* That function's behavior is really odd and easy to be used in the wrong way. The callback function isn't intended to return true/false for matching items, but return -1/0/1 like sorting functions. The tests seemingly only worked by chance as returning true/false is doing pretty much the opposite of what the callback function is supposed to do.
Commits
-------
1675864032 [Security] Fix event propagation for globally registered security events
This PR was merged into the 5.2 branch.
Discussion
----------
[TwigBridge] allow null values in form helpers
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix #39591| License | MIT
| Doc PR |
Commits
-------
f908047c6b allow null values in form helpers
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 5.2 branch.
Discussion
----------
[Security] Add RememberMe Badge to LoginLinkAuthenticator
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
I'm replacing a custom home-made magic link authenticator by the Symfony one, and I missed this behavior. I had to use a EventListener to add the badge to the passeport.
I'm not sure, if the badge were missing on purpose /cc @weaverryan @wouterj
Commits
-------
d38fc4d678 Add RememberMe Badge to LoginLinkAuthenticator
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Notifier] Fix component version constraint in bridges
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | np
| Tickets | -
| License | MIT
| Doc PR | -
Composer does not resolve `~5.3.0` to 5.x-dev with `--prefer-lowest` actually.
Commits
-------
bcdd5da849 [Notifier] Fix component version constraint in bridges
