[Messenger] Added a middleware that validates messages #26648

Nyholm · 2018-03-23T08:55:07Z

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets
License	MIT
Doc PR	coming

This is inspired by Fervo. It runs the validator over messages implementing the ValidatedMessageInterface.

sroze · 2018-03-23T09:04:03Z

src/Symfony/Bundle/FrameworkBundle/Resources/config/messenger.xml

+        <service id="messenger.middleware.validator" class="Symfony\Component\Messenger\Middleware\ValidatingMiddleware">
+            <argument type="service" id="validator" />
+
+            <tag name="message_bus_middleware" priority="8" />


Any reasoning for such priority? I'd argue it should be higher by default as it would be one of the most important "first steps".

sroze · 2018-03-23T09:04:58Z

src/Symfony/Component/Messenger/Middleware/ValidatingMiddleware.php

+ * @author Magnus Nordlander <[email protected]>
+ * @author Tobias Nyholm <[email protected]>
+ */
+class ValidatingMiddleware implements MiddlewareInterface


ValidationMiddleware feels better to me and is more coherent with the other middleware names 🤔 (except LoggingMiddleware 🙊)

sroze · 2018-03-23T09:06:20Z

src/Symfony/Component/Messenger/Middleware/ValidatingMiddleware.php

+            }
+        }
+
+        $next($message);


Don't forget the return here.

sroze · 2018-03-23T09:07:00Z

src/Symfony/Component/Messenger/Middleware/ValidatingMiddleware.php

+ */
+class ValidatingMiddleware implements MiddlewareInterface
+{
+    protected $validator;


Why would this one be protected? I'd close first if we can so private, nah?

sroze · 2018-03-24T14:34:33Z

The only remaining question is "Should this validation be enabled by default" (i.e. shouldn't we drop the ValidatedMessageInterface).

To me, it sounds like we should enable it by default because:

It's a common practice to validate messages before sending them to a bus
There is no real "risk" as it would require the developers to add the @Valid annotation (or similar configuration) on the message's fields to have entities validated
We can add an opt-in/opt-out configuration later if it's too much of a problem.

What do you think? /cc @symfony/deciders

Nyholm · 2018-03-26T10:55:49Z

I've squashed my commits and added validation by default. Validating a message without validation metadata will always pass.

ogizanagi · 2018-03-26T20:27:36Z

src/Symfony/Component/Messenger/Exception/ValidationFailedException.php

+        parent::__construct($this->__toString());
+    }
+
+    public function __toString()


AFAIK, we never defined __toString method on exceptions in the core. Not sure this is desired now.

ogizanagi · 2018-03-26T20:28:46Z

src/Symfony/Component/Messenger/Exception/ValidationFailedException.php

+        return $this->violatingMessage;
+    }
+
+    public function getViolations()


Missing return type?

ogizanagi · 2018-03-26T20:29:19Z

src/Symfony/Component/Messenger/Exception/ValidationFailedException.php

+    protected $violations;
+    protected $violatingMessage;
+
+    public function __construct($violatingMessage, ConstraintViolationListInterface $violations)


Missing a @param object $violatingMessage docblock?

ogizanagi · 2018-03-26T20:29:41Z

src/Symfony/Component/Messenger/Middleware/ValidationMiddleware.php

+class ValidationMiddleware implements MiddlewareInterface
+{
+    /**
+     * @var ValidatorInterface


Can be removed as there is already a typehint on the constructor

Nyholm · 2018-03-27T07:41:00Z

Thank you for the review. I've updated accordingly. I've also rebased the PR on master.

ogizanagi · 2018-03-27T07:48:52Z

src/Symfony/Component/Messenger/Exception/ValidationFailedException.php

+        $this->violatingMessage = $violatingMessage;
+        $this->violations = $violations;
+
+        parent::__construct($this->__toString());


- parent::__construct($this->__toString()); + parent::__construct(sprintf("Message of type %s failed validation", get_class($this->violatingMessage));

as the __toString method is now removed?

sroze

Almost there, thanks for the work.

I slept on it and I believe we need an opt-out. It doesn't need to be complicated: a boolean at framework.messenger.validation would do it. Could you add that?

sroze · 2018-03-27T07:52:32Z

src/Symfony/Component/Messenger/Exception/ValidationFailedException.php

+
+    /**
+     * @param object                           $violatingMessage
+     * @param ConstraintViolationListInterface $violations


We don't need this one.

Okey. Thanks

Nyholm · 2018-03-27T07:55:58Z

I agree. But there will be plenty of merge conflicts.

I will add "opt-out" config once #26647 is merged.

Nyholm · 2018-03-27T11:03:48Z

I've rebased my PR and added a way to opt-out from message validation

ogizanagi · 2018-03-27T11:43:49Z

src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php

+                                    ->end()
+                                ->end()
+                                ->arrayNode('validation')
+                                    ->canBeDisabled()


- ->canBeDisabled() + ->{!class_exists(FullStack::class) && class_exists(Validation::class) ? 'canBeDisabled' : 'canBeEnabled'}()

so it does not appear as enabled when the validator component isn't installed?

Excellent idea. I was looking for something like this. And if someone tries to use validation without the validation component I'll throw an exception.

Indeed, we use to throw such exceptions from the FrameworkExtension :)

chalasr · 2018-03-29T12:08:01Z

src/Symfony/Component/Messenger/Exception/ValidationFailedException.php

+class ValidationFailedException extends \RuntimeException implements ExceptionInterface
+{
+    protected $violations;
+    protected $violatingMessage;


if no inheritance use case for these properties in core then they should be private

chalasr · 2018-03-29T12:40:52Z

src/Symfony/Component/Messenger/Exception/ValidationFailedException.php

+     */
+    public function __construct($violatingMessage, ConstraintViolationListInterface $violations)
+    {
+        $this->violatingMessage = $violatingMessage;


Is it really needed? I'm used to handle one command at a time so I always have the message at hand, am I missing a use case? The existing NoHandlerForMessageException doesn't expose it

The difference is that the NoHandlerForMessageException is a logic exception (or at least, should be to me), it is meant to fail badly. No need to access the exception programmatically and retrieve the issuing message.

ValidationFailedException is a runtime exception, meant to be caught and handled/transformed to a better representation (e.g: an API problem response). It can also be used in a profiler panel or whatever :)

Anyway, even if we often handle one message at the time, use-cases with multiple messages do exist. We should cover them. 👍

sroze · 2018-03-29T14:46:41Z

src/Symfony/Component/Messenger/Exception/ValidationFailedException.php

+        $this->violatingMessage = $violatingMessage;
+        $this->violations = $violations;
+
+        parent::__construct(sprintf('Message of type "%s" failed validation', get_class($this->violatingMessage)));


Missing dot at the end 😉

Nyholm · 2018-03-29T18:37:07Z

Thank you for the reviews. I've updated the PR accordingly

…ception (ogizanagi) This PR was merged into the 4.1-dev branch. Discussion ---------- [Messenger] Make NoHandlerForMessageException a logic exception | Q | A | ------------- | --- | Branch? | master  | Bug fix? | no | New feature? | no  | BC breaks? | no  | Deprecations? | no  | Tests pass? | yes  | Fixed tickets | symfony/symfony#26648 (comment)  | License | MIT | Doc PR | N/A  To me, a missing handler for a message is a program logic exception (or misconfiguration). Even if it's only detected at runtime here. It's the same as `ServiceNotFoundException` which even is an `\InvalidArgumentException`. Could eventually also be the case here. Commits ------- 0489bbd948 [Messenger] Make NoHandlerForMessageException a logic exception

…ception (ogizanagi) This PR was merged into the 4.1-dev branch. Discussion ---------- [Messenger] Make NoHandlerForMessageException a logic exception | Q | A | ------------- | --- | Branch? | master  | Bug fix? | no | New feature? | no  | BC breaks? | no  | Deprecations? | no  | Tests pass? | yes  | Fixed tickets | #26648 (comment)  | License | MIT | Doc PR | N/A  To me, a missing handler for a message is a program logic exception (or misconfiguration). Even if it's only detected at runtime here. It's the same as `ServiceNotFoundException` which even is an `\InvalidArgumentException`. Could eventually also be the case here. Commits ------- 0489bbd [Messenger] Make NoHandlerForMessageException a logic exception

sroze

Can you add some tests? That it adds (and not if disabled) the middleware.

sroze · 2018-03-30T09:47:42Z

src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php

+
+        if ($config['middlewares']['validation']['enabled']) {
+            if (!$container->has('validator')) {
+                throw new LogicException('The Validation middleware is only available when the validator component is installed and enabled. Try running "composer require symfony/validator".');


- validator component + Validator component

Nyholm · 2018-04-03T09:40:02Z

I've fixed the typo and added tests. I've also rebased on master. The Travis tests failure seams unrelated.

sroze · 2018-04-03T12:23:55Z

@fabpot as you disagreed with the Doctrine one... WDYT about this one? 🤔

fabpot · 2018-04-03T12:26:31Z

This one is fine as this is about integrating various Symfony components.

sroze

@Nyholm can you squash and rebase?

fabpot · 2018-04-03T18:07:42Z

@sroze no need to rebase (as there are no merge commits) and no need to rebase (as there are no conflicts). Our gh tools does that automatically :)

sroze · 2018-04-03T18:16:17Z

@fabpot that rebase request was meant so that we would have green ticks when I gh merge it :)
But yeah, they aren't related to I guess I can... 💣.

sroze · 2018-04-03T20:18:25Z

Thank you @Nyholm.

… (Nyholm) This PR was squashed before being merged into the 4.1-dev branch (closes #26648). Discussion ---------- [Messenger] Added a middleware that validates messages | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | | License | MIT | Doc PR | coming This is inspired by [Fervo](https://github.com/fervo/ValidatedMessage). It runs the validator over messages implementing the `ValidatedMessageInterface`. Commits ------- 43a5171 [Messenger] Added a middleware that validates messages

sroze · 2018-04-03T21:14:30Z

One of the failing tests was actually related. Fixed in #26782.

Nyholm · 2018-04-04T09:29:20Z

Thank you for merging

carsonbot added Status: Needs Review Feature Status: Needs Work and removed Status: Needs Review labels Mar 23, 2018

sroze suggested changes Mar 23, 2018

View reviewed changes

nicolas-grekas added this to the 4.1 milestone Mar 23, 2018

chalasr added the Messenger label Mar 23, 2018

Nyholm force-pushed the middleware-validator branch from daf3610 to 4889be7 Compare March 26, 2018 10:55

carsonbot added Status: Reviewed and removed Status: Needs Work labels Mar 26, 2018

sroze approved these changes Mar 26, 2018

View reviewed changes

carsonbot added Status: Needs Work and removed Status: Reviewed labels Mar 26, 2018

ogizanagi suggested changes Mar 26, 2018

View reviewed changes

Nyholm force-pushed the middleware-validator branch from 04d3572 to d7f72c0 Compare March 27, 2018 07:40

ogizanagi reviewed Mar 27, 2018

View reviewed changes

carsonbot added Status: Reviewed and removed Status: Needs Work labels Mar 27, 2018

ogizanagi approved these changes Mar 27, 2018

View reviewed changes

sroze suggested changes Mar 27, 2018

View reviewed changes

carsonbot added Status: Needs Work and removed Status: Reviewed labels Mar 27, 2018

Nyholm force-pushed the middleware-validator branch 2 times, most recently from bac60a9 to ab6c055 Compare March 27, 2018 11:02

ogizanagi reviewed Mar 27, 2018

View reviewed changes

chalasr reviewed Mar 29, 2018

View reviewed changes

ogizanagi mentioned this pull request Mar 29, 2018

[Messenger] Make NoHandlerForMessageException a logic exception #26706

Merged

sroze suggested changes Mar 29, 2018

View reviewed changes

sroze suggested changes Mar 30, 2018

View reviewed changes

Nyholm force-pushed the middleware-validator branch from 3111acc to a1f086f Compare April 3, 2018 09:37

sroze approved these changes Apr 3, 2018

View reviewed changes

carsonbot added Status: Reviewed and removed Status: Needs Work labels Apr 3, 2018

[Messenger] Added a middleware that validates messages

43a5171

sroze force-pushed the middleware-validator branch from a1f086f to 43a5171 Compare April 3, 2018 20:18

sroze merged commit 43a5171 into symfony:master Apr 3, 2018

Nyholm deleted the middleware-validator branch April 4, 2018 09:29

ogizanagi mentioned this pull request Apr 9, 2018

[Messenger] Define multiple buses from the framework.messenger.buses configuration #26864

Merged

javiereguiluz mentioned this pull request Apr 20, 2018

[Messenger] Added a middleware that validates messages symfony/symfony-docs#9641

Closed

fabpot mentioned this pull request May 7, 2018

Release v4.1.0-BETA1 #27181

Merged

ogizanagi mentioned this pull request Oct 11, 2018

[Messenger] Document the validation middleware symfony/symfony-docs#10474

Closed

[Messenger] Added a middleware that validates messages #26648

[Messenger] Added a middleware that validates messages #26648

Conversation

Nyholm commented Mar 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sroze commented Mar 24, 2018 • edited Loading

Nyholm commented Mar 26, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nyholm commented Mar 27, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sroze left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nyholm commented Mar 27, 2018

Nyholm commented Mar 27, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ogizanagi Mar 29, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nyholm commented Mar 29, 2018

sroze left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nyholm commented Apr 3, 2018

sroze commented Apr 3, 2018 • edited Loading

fabpot commented Apr 3, 2018

sroze left a comment

Choose a reason for hiding this comment

fabpot commented Apr 3, 2018

sroze commented Apr 3, 2018 • edited Loading

sroze commented Apr 3, 2018

sroze commented Apr 3, 2018

Nyholm commented Apr 4, 2018

Nyholm commented Mar 23, 2018 •

edited

Loading

sroze commented Mar 24, 2018 •

edited

Loading

ogizanagi Mar 29, 2018 •

edited

Loading

sroze left a comment •

edited

Loading

sroze commented Apr 3, 2018 •

edited

Loading

sroze commented Apr 3, 2018 •

edited

Loading