-
-
Notifications
You must be signed in to change notification settings - Fork 164
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AggregateRoot Method is called if Argument has no type-hint #341
Comments
To my knowledge, our packages wouldn't call a custom method like |
Please see https://github.com/fabianpnke/laravel-event-sourcing-issue-341-demo I've managed to reproduce a behaviour in that the problem results in a 500 Server error by removing a type hint from the method. |
Hi, same here, when there is a public method in an aggregate with non typed params the app totally breaks. The break occurs exactly inside the apply function of AggregateRoot.php, in the Handlers section. |
mixed doesnt work as a type either. |
I've also ran into this bug. I believe the issue is in the Possible Fix Maybe a method could be added to Temporary Solution I added a second unused argument to my function to get things working. Not ideal but will work for now until this is addressed. |
I've opened a PR in the better-types repository that can hopefully help address this issue. spatie/better-types#3 |
@freekmurze I've tested the latest changes in version |
Hi @zackrowe and @freekmurze |
PHP Version: 8.1.5
Laravel Version: 9.11.0
spatie/laravel-event-sourcing Version: 7.2.0
Hi there,
Today I came across the Situation where Method
two
was getting called when using the AggregateRoot with Methodone
inside the Application. I wondered why this was happening cause I had never used the AggregateRoot with Methodtwo
anywhere yet. After some experimenting and debugging, I found out that this only happens if the Argument in Methodtwo
is not type-hinted.Here are some examples for a better understanding:
Scenario 1 (
two
is called):Scenario 2 (
two
is not called):Is this an expected behaviour or a bug/defect?
Thanks for checking and clarifying,
Fabian
The text was updated successfully, but these errors were encountered: