Open mk-conn opened 5 years ago
So someone else has seen this a while ago but I've never been able to reproduce it. The ErrorIdAllocatorInterface
is type-hinted in the constructor as nullable, so the Laravel container shouldn't be trying to instantiate one if there isn't one bound in the container.
I'm at a loss as to what could cause this and have no way of debugging it as I've never been able to reproduce.
What version of this package are you on, and what version of Laravel are you on?
Can you try the instructions in this comment on the previous issue: https://github.com/cloudcreativity/laravel-json-api/issues/307#issuecomment-508040774
Can you try the instructions in this comment on the previous issue: #307 (comment)
Will do, when I get tinker back to work ... there is currently an issue with PHP 7.3...
What version of this package are you on, and what version of Laravel are you on?
Laravel 6.4, Laravel-Json-Api: 1.5.0
>>> $p = app(\CloudCreativity\LaravelJsonApi\Contracts\Exceptions\ExceptionParserInterface::class);
=> CloudCreativity\LaravelJsonApi\Exceptions\ExceptionParser {#3713}
>>> wtf -a
InvalidArgumentException with message 'No most-recent exception'
--
0: () at vendor/psy/psysh/src/Context.php:190
1: Psy\Context->getLastException() at vendor/psy/psysh/src/Command/WtfCommand.php:94
2: Psy\Command\WtfCommand->execute() at vendor/symfony/console/Command/Command.php:255
3: Symfony\Component\Console\Command\Command->run() at vendor/psy/psysh/src/Shell.php:803
4: Psy\Shell->runCommand() at vendor/psy/psysh/src/Shell.php:405
5: Psy\Shell->getInput() at vendor/psy/psysh/src/ExecutionLoopClosure.php:40
6: Psy\{closure}() at vendor/psy/psysh/src/ExecutionClosure.php:101
7: Psy\ExecutionClosure->execute() at vendor/psy/psysh/src/ExecutionLoop.php:33
8: Psy\ExecutionLoop->run() at vendor/psy/psysh/src/Shell.php:351
9: Psy\Shell->doRun() at vendor/symfony/console/Application.php:149
10: Symfony\Component\Console\Application->run() at vendor/psy/psysh/src/Shell.php:316
11: Psy\Shell->run() at vendor/laravel/tinker/src/Console/TinkerCommand.php:68
12: Laravel\Tinker\Console\TinkerCommand->handle() at n/a:n/a
13: call_user_func_array() at vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:32
14: Illuminate\Container\BoundMethod::Illuminate\Container\{closure}() at vendor/laravel/framework/src/Illuminate/Support/helpers.php:520
15: value() at vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:90
16: Illuminate\Container\BoundMethod::callBoundMethod() at vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:34
17: Illuminate\Container\BoundMethod::call() at vendor/laravel/framework/src/Illuminate/Container/Container.php:591
18: Illuminate\Container\Container->call() at vendor/laravel/framework/src/Illuminate/Console/Command.php:202
19: Illuminate\Console\Command->execute() at vendor/symfony/console/Command/Command.php:255
20: Symfony\Component\Console\Command\Command->run() at vendor/laravel/framework/src/Illuminate/Console/Command.php:189
21: Illuminate\Console\Command->run() at vendor/symfony/console/Application.php:934
22: Symfony\Component\Console\Application->doRunCommand() at vendor/symfony/console/Application.php:273
23: Symfony\Component\Console\Application->doRun() at vendor/symfony/console/Application.php:149
24: Symfony\Component\Console\Application->run() at vendor/laravel/framework/src/Illuminate/Console/Application.php:90
25: Illuminate\Console\Application->run() at vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php:131
26: Illuminate\Foundation\Console\Kernel->handle() at artisan:33
>>>
Thanks.
So that's whats totally weird about this issue... you don't get an exception when resolving the exception parser out of the container in Tinker. So I have no idea what's causing it in a different scenario.
My question would be: when you say this:
getting this BindingResolutionException and I do not understand why this happens - the request is handled just fine, nothing in the error log...
The request is handled fine and nothing is in the error log. So what are you doing to trigger that exception? What's the scenario/trigger for it and how are you seeing it?
I'm seeing something similar after updating to PHP 7.4 and Laravel 5.6.
2020/02/11 02:39:50 [error] 6#6: *26 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [CloudCreativity\LaravelJsonApi\Contracts\Resolver\ResolverInterface] is not instantiable while building [CloudCreativity\LaravelJsonApi\Routing\Route]. in /var/www/vendor/laravel/framework/src/Illuminate/Container/Container.php:933
If I tinker and do this, it's fine:
>>> app(\CloudCreativity\LaravelJsonApi\Contracts\Resolver\ResolverInterface::class)
=> CloudCreativity\LaravelJsonApi\Resolver\AggregateResolver {#3833}
This was running in a Docker container. I was originally letting the container run as root, and my composer dependencies were installed as the root user. However, after taking ownership of the vendor
directory in my host (sudo chown -R $USER:$USER vendor
) and restarting the PHP-FPM container running as me instead of root, it seems to all be working fine.
Ah right, that's really useful to hear - implies it's a permissions issue on the files rather than a problem in the package.
Same problem. I debugged with xdebug. I found that the problem started with the token has expired and Tymon\JWTAuth\Claims\Expiration
throw an exception.
For the record, I ran into this issue, too, and found the root was:
The stream or file "/var/www/html/storage/logs/laravel-2021-09-20.log" could not be opened in append mode: failed to open stream: Permission denied
Permission issue on the storage/
directory. The exception got through trying to convert it to a JSON response.
Tip for others seeing this: look at the user/group of the web service vs the user/group of the sync'd files. In docker, the files are mounted as root:root, and your web server is most likely running as www-data:www-data.
Hey,
getting this BindingResolutionException and I do not understand why this happens - the request is handled just fine, nothing in the error log... (exception must be catched somewhere)
Any idea?