This PR was squashed before being merged into the 4.1-dev branch (closes#26945).
Discussion
----------
[Messenger] Support configuring messages when dispatching
| Q | A
| ------------- | ---
| Branch? | master <!-- see below -->
| Bug fix? | no
| New feature? | yes <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | see CI checks <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | todo
For now, this is mainly a RFC to get your opinion on such a feature (so it misses proper tests).
Supporting wrapped messages out-of-the-box would mainly allow to easily create middlewares that should act only or be configured differently for specific messages (by using wrappers instead of making messages implements specific interfaces and without requiring dedicated buses). For instance, I might want to track specific messages and expose metrics about it.
The Symfony Serializer transport (relates to #26900) and Validator middleware serve as guinea pigs for sample purpose here. But despite message validation usually is simple as it matches one use-case and won't require specific validation groups in most cases, I still think it can be useful sometimes. Also there is the case of the [`AllValidator` which currently requires using a `GroupSequence`](https://github.com/symfony/symfony/pull/26477) as a workaround, but that could also be specified directly in message metadata instead.
## Latest updates
PR updated to use a flat version of configurations instead of wrappers, using an `Envelope` wrapper and a list of envelope items.
Usage:
```php
$message = Envelope::wrap(new DummyMessage('Hello'))
->with(new SerializerConfiguration(array(ObjectNormalizer::GROUPS => array('foo'))))
->with(new ValidationConfiguration(array('foo', 'bar')))
;
```
~~By default, Messenger protagonists receive the original message. But each of them can opt-in to receive the envelope instead, by implementing `EnvelopeReaderInterface`.
Then, they can read configurations from it and forward the original message or the envelope to another party.~~
Senders, encoders/decoders & receivers always get an `Envelope`.
Middlewares & handlers always get a message. But middlewares can opt-in to receive the envelope instead, by implementing `EnvelopeReaderInterface`.
Commits
-------
749054a1e8 [Messenger] Support configuring messages when dispatching
This PR was merged into the 4.1-dev branch.
Discussion
----------
Rename middlewares to middleware
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
`middleware` is uncountable in English (like software or information). So, I've removed the `s` everywhere. We can probably be a bit more explicit if we think it makes thing easier to understand like I've done in one class, like `middlewareHandler`.
Commits
-------
9ae7c11805 Do not fix the `middleware` XML name anymore
52e7500edb removed usage of middlewares
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] Add missing `@experimental` annotations
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | ø
So we have all the Messenger interfaces tagged with `@experimental`.
Commits
-------
7f875cb52b Add missing `@experimental` annotations
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] Fix missing s/tolerate_no_handler/allow_no_handler/g
| Q | A
| ------------- | ---
| Branch? | master <!-- see below -->
| Bug fix? | yes
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
Spotted while rebasing #26945: some places weren't updated. Most are in tests and not that much important but should be updated for consistency. But moreover, the `AllowNoHandlerMiddleware` wiring in DI was still referencing the old class name.
Commits
-------
e7cfb59480 [Messenger] Fix missing s/tolerate_no_handler/allow_no_handler/g
This PR was merged into the 4.1-dev branch.
Discussion
----------
[HttpKernel] Add Kernel::getAnnotatedClassesToCompile()
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Now that apps are usually bundle-less, we're missing a way to defined the classes to parse annotations for. Here is a PR fixing this by allowing ppl to define a new `getAnnotatedClassesToCompile()` on their kernel when needed.
Commits
-------
1d2a49aeb6 [HttpKernel] Add Kernel::getAnnotatedClassesToCompile()
This PR was merged into the 4.1-dev branch.
Discussion
----------
[FrameworkBundle][Messenger] Remove convention-based service id generation for buses
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes (DX)
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Service ids for buses are user facing ids: ppl *will* have to deal with them when wiring their services.
Like for cache pools, we should ask ppl to declare them using full identifiers, instead of having a convention-based way to turn a name into and id (which is something nobody will be able to remember at some point.)
Commits
-------
c7a0045cbd [FrameworkBundle][Messenger] Remove convention-based service id generation for buses
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] Relax messenger config and fix some bugs
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
After playing a little with the config of this component I found some bugs around.
Reproducer:
1. Install a fresh Symfony flex project with `^4.0@dev` dependencies
2. Add the `symfony/messenger` requirement
3. Add the following configuration separately:
Note that `symfony/serializer` has not been installed yet. ATM it's not required.
----------------------
Configuring my custom transport (not amqp):
```yaml
framework:
messenger:
transports:
custom: 'my_transport://localhost/msgs'
routing:
'*': custom
```
**Before** (Current behaviour):
Threw a logic exception, IMO unrelated at this point:
> Using the default encoder/decoder, Symfony Messenger requires the Serializer. Enable it or install it by running "composer require symfony/serializer-pack".
**After** (Proposal):
Pass! The Messenger's serializer config is disabled by definition because the Serializer component is not installed yet, then the related (default) encoder/decoder aliases are invalid, so the amqp transport factory service is removed altogether.
----------------------
According to the previous exception I configured my custom encoder/decoder services:
```yaml
framework:
messenger:
encoder: App\Serializer\Serializer
decoder: App\Serializer\Serializer
transports:
custom: 'my_transport://localhost/msgs'
routing:
'*': custom
```
**Before**:
The same exception has been thrown, now a bit vague according to the config:
> Using the default encoder/decoder, Symfony Messenger requires the Serializer. Enable it or install it by running "composer require symfony/serializer-pack".
**After**:
Pass! the serializer is disabled by definition but there is custom encoder/decoder services, so let's keep the amqp transport factory with their custom encoder/decoder deps.
----------------------
Just enabling the serializer option:
```yaml
framework:
messenger:
serializer: true
```
**Before**:
Pass! Unexpected, as there is no transport configuration the exception wasn't thrown and still keeps the amqp transport factory service with invalid encoder/decoder (Serializer) dependencies.
**After**:
The Serializer config & support is verified if it's enabled regardless of the transport configuration and this exception is thrown for this case:
> The default Messenger serializer cannot be enabled as the Serializer support is not enabled.
I've removed the "install" part because at this point only we're checking whether the `framework.serializer` is enabled or not, so the next step after that should be enable the Serializer support in `framework.serializer`, which already verify whether the Serializer component is installed or not. IMO "composer require symfony/serializer-pack" should be there and not here. Also because `symfony/serializer` is not a hard dependency of this component.
----------------------
By last, I disabled the serializer option manually:
```yaml
framework:
messenger:
serializer: false
transports:
custom: 'my_transport://localhost/msgs'
routing:
'*': custom
```
**Before**:
I received this DI exception:
> The service "messenger.transport.amqp.factory" has a dependency on a non-existent service "messenger.transport.serializer".
**After**:
Pass! (same behaviour that the first example)
----------------------
As I explained earlier, this PR enables or disables the Messenger's serializer config based on the current Symfony platform and whether the Serializer component is installed or not, like other config with similar behaviour.
Tests included :)
Cheers!
Commits
-------
a05e2e2c3b Relax Messenger config and fix some bugs
* 4.0:
use brace-style regex delimiters
Fixed typo RecursiveIterator -> RecursiveIteratorIterator
[Cache] fix logic for fetching tag versions on TagAwareAdapter
[FrameworkBundle] Remove dead code
[FrameworkBundle] Use the correct service id for CachePoolPruneCommand in its compiler pass
Hide short exception trace by default
[Doctrine Bridge] fix priority for doctrine event listeners
[Validator] make phpdoc of ObjectInitializerInterface interface more accurate
[Validator] fixes phpdoc reference to an interface that was removed in Symfony 3.0
* 3.4:
use brace-style regex delimiters
Fixed typo RecursiveIterator -> RecursiveIteratorIterator
[Cache] fix logic for fetching tag versions on TagAwareAdapter
[FrameworkBundle] Use the correct service id for CachePoolPruneCommand in its compiler pass
Hide short exception trace by default
[Doctrine Bridge] fix priority for doctrine event listeners
[Validator] make phpdoc of ObjectInitializerInterface interface more accurate
[Validator] fixes phpdoc reference to an interface that was removed in Symfony 3.0
* 2.8:
use brace-style regex delimiters
Fixed typo RecursiveIterator -> RecursiveIteratorIterator
[Validator] make phpdoc of ObjectInitializerInterface interface more accurate
* 2.7:
use brace-style regex delimiters
Fixed typo RecursiveIterator -> RecursiveIteratorIterator
[Validator] make phpdoc of ObjectInitializerInterface interface more accurate
This PR was merged into the 4.1-dev branch.
Discussion
----------
Show the deprecations tab by default in the logger panel
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Similar to #26398, I propose to display the deprecation tab by default when there are no error logs but there are some deprecations.
Commits
-------
d27b158e4f Show the deprecations tab by default in the logger panel
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] Rename TolerateNoHandler to AllowNoHandlerMiddleware
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
I was surprised by the word "tolerate", and by the missing "middleware" suffix.
This way would be less surprizing I believe.
Commits
-------
5434780d58 [Messenger] Rename TolerateNoHandler to AllowNoHandlerMiddleware
This PR was squashed before being merged into the 3.4 branch (closes#27158).
Discussion
----------
[Cache] fix logic for fetching tag versions on TagAwareAdapter
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #27147
| License | MIT
| Doc PR | -
There was a problem introduced in https://github.com/symfony/symfony/pull/27007 which breaks tag invalidation.
From what I can see there were some cases when the actual tag versions were never fetched from the tags pool and version=0 was used.
@nicolas-grekas this is my attempt of understanding the logic within `TagAwareAdapter`. Please have a look if this makes sense to you 😉
Commits
-------
d3790cadcd [Cache] fix logic for fetching tag versions on TagAwareAdapter
This PR was merged into the 3.4 branch.
Discussion
----------
[Console] By default hide the short exception trace line from exception messages in Symfony's commands
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
After https://github.com/symfony/symfony/pull/24131 this was in my contribution list since then.
Maybe it should be taken as a good practice when we build console commands, **use the exception classes of the Console component as much as possible to show a better message style to the end user**.
(See the before/after effect in the referenced PR)
Commits
-------
11f3c455d4 Hide short exception trace by default
This PR was merged into the 4.1-dev branch.
Discussion
----------
[FrameworkBundle] Hide some lock-related services
| Q | A
| ------------- | ---
| Branch? | 4.1
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
I don't know why, but I missed these in #26921
Commits
-------
d06d8b2573 [FrameworkBundle] Hide some lock-related services
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] Add a new time limit receiver
| Q | A
| ------------- | ---
| Branch? | master for features
| Bug fix? | no
| New feature? | yes
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no
| Tests pass? | yes
| License | MIT
New feature to add a time limit option to the ConsumeMessagesCommand.
```
bin/console messenger:consume-messages <receiver-name> -t 3600
```
Commits
-------
5536ee1b3e Add a new time limit receiver
This PR was squashed before being merged into the 4.1-dev branch (closes#27129).
Discussion
----------
[Messenger] Rename Adapters to Transports
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | ø
Last of our tasks on the "plan to beta", renaming "adapters" to "transports". This is a term that makes more sense and is commonly used within the "queue community".
Commits
-------
13b747565f [Messenger] Rename Adapters to Transports
This PR was squashed before being merged into the 4.1-dev branch (closes#27122).
Discussion
----------
[DI] Minor performance tweak in PriorityTaggedServiceTrait
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
When this feature was added, we were limited to older php versions that didn't have the argument unpacking feature. This should improve performance a little (also came up with php inspections).
Commits
-------
94314f9d55 [DI] Minor performance tweak in PriorityTaggedServiceTrait
This PR was squashed before being merged into the 4.1-dev branch (closes#27123).
Discussion
----------
[DebugBundle][HttpKernel] Update var-dumper requirement for components using SourceContextProvider
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
The DebugBundle is using the SourceContextProvider class that was introduced in v4.1
Commits
-------
b0b9060237 [DebugBundle][HttpKernel] Update var-dumper requirement for components using SourceContextProvider
This PR was squashed before being merged into the 3.4 branch (closes#27135).
Discussion
----------
[FrameworkBundle] Use the correct service id for CachePoolPruneCommand in its compiler pass
… CachePoolPruneCommand in its compiler pass
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #27134 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
<!--
Write a short README entry for your feature/bugfix here (replace this comment block.)
This will help people understand your PR and can be used as a start of the Doc PR.
Additionally:
- Bug fixes must be submitted against the lowest branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too).
- Features and deprecations must be submitted against the master branch.
-->
Commits
-------
32c7ee35be [FrameworkBundle] Use the correct service id for CachePoolPruneCommand in its compiler pass
