Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Messenger] make dispatch(), handle() and send() methods return Envelope#28983

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@nicolas-grekas
Copy link
Member

@nicolas-grekasnicolas-grekas commentedOct 25, 2018
edited
Loading

QA
Branch?4.2
Bug fix?no
New feature?yes
BC breaks?no (already broken ;) )
Deprecations?no
Tests pass?yes
Fixed tickets-
LicenseMIT
Doc PR-

Follow up of#28909. We can do better than returnvoid: let's returnEnvelope!
This means middleware and senders should also returnEnvelope, so that we can typically read back the stamps that were added during the sending process (eg to get the Kafka queue id).

ping@dunglas as we discussed that first on Slack, and@sroze as we confirmed interest IRL today.

(User handlers don't know anything about envelopes so they still should returnvoid - use senders or middleware if you need to populate/read envelopes.)

sroze and Tobion reacted with thumbs up emojidunglas reacted with heart emoji
Copy link
Contributor

@srozesroze left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yes, much better. That sounds good.

* @final
*/
finalclass Envelope
class Envelope
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Why is the reason do remove PHP final here? I understand that the@final is not enforced, probably to allow people to override the class, but then what's the point?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

The tests require the change for mocks.

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

(In order to mock the new return values.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

You could consider to introduce an interface or to just create the Envelope object in tests (instead of mocking it). I don't see it mocked anywhere by the way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Data object -> no mocks. In any case, removingfinal "just" for the tests sounds like a terrible idea.

jakzal, Tobion, sroze, ogizanagi, sstok, and modiamir reacted with thumbs up emoji
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I agree with@fabpot that Envelope does not need to be mocked and thus could remain final.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I agree with@fabpot too

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

reverted, the class is now really final again

Copy link
Contributor

@TobionTobion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I like all the recent changes in Messenger.

@nicolas-grekas
Copy link
MemberAuthor

PR rebased, ready.

@sroze
Copy link
Contributor

Thank you@nicolas-grekas.

@srozesroze merged commit4b0e015 intosymfony:masterOct 26, 2018
sroze added a commit that referenced this pull requestOct 26, 2018
…ds return Envelope (nicolas-grekas)This PR was merged into the 4.2-dev branch.Discussion----------[Messenger] make dispatch(), handle() and send() methods return Envelope| Q             | A| ------------- | ---| Branch?       | 4.2| Bug fix?      | no| New feature?  | yes| BC breaks?    | no (already broken ;) )| Deprecations? | no| Tests pass?   | yes| Fixed tickets | -| License       | MIT| Doc PR        | -Follow up of#28909. We can do better than return `void`: let's return `Envelope`!This means middleware and senders should also return `Envelope`, so that we can typically read back the stamps that were added during the sending process (eg to get the Kafka queue id).ping@dunglas as we discussed that first on Slack, and@sroze as we confirmed interest IRL today.(User handlers don't know anything about envelopes so they still should return `void` - use senders or middleware if you need to populate/read envelopes.)Commits-------4b0e015 [Messenger] make dispatch(), handle() and send() methods return Envelope
@nicolas-grekasnicolas-grekas deleted the messenger-return-envelope branchOctober 26, 2018 11:11
fabpot added a commit that referenced this pull requestOct 27, 2018
…wareInterface bc-break (skalpa)This PR was merged into the 4.2-dev branch.Discussion----------[Messenger] Fix DoctrineTransactionMiddleware after MiddlewareInterface bc-break| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | -| License       | MIT| Doc PR        | -Fixes `DoctrineTransactionMiddleware` that got broken by#28983, and adds tests.Commits-------378ca06 Fix DoctrineTransactionMiddleware after MiddlewareInterface bc-break
This was referencedNov 3, 2018
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@fabpotfabpotfabpot left review comments

@dunglasdunglasdunglas approved these changes

+4 more reviewers

@jakzaljakzaljakzal left review comments

@TobionTobionTobion approved these changes

@ogizanagiogizanagiogizanagi approved these changes

@srozesrozesroze approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.2

Development

Successfully merging this pull request may close these issues.

8 participants

@nicolas-grekas@sroze@fabpot@dunglas@jakzal@Tobion@ogizanagi@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp