ServiceProvider not found during deployment

I have a particular project that consistently throws a bunch of identical errors every time I deploy my project. I sync my project using rsync using the -a flag and --exclude-from to which I pass a file where the vendor folder is listed (among other stuff).

The error that occurs is the following:

production.ERROR: Class "Barryvdh\Debugbar\ServiceProvider" not found

I'm suspecting it has something to do with the autoloading but I do not know enough about how that works in practice to debug it.

So, here's the weird parts:

If I remove that package (barryvdh/laravel-debugbar), the error persists but with another package.
I have another project with the same setup, but different packages (but both have barryvdh/laravel-debugbar). This project does not yield any errors on synchronization.

The error doesn't seem to affect the web app at all.

After deployment/synchronization I run composer install --no-dev -optimize-autoloader.

Any help is greatly appreciated.

Nakov

4 years ago

Level 73

The Laravel Debugbar should not be installed in production, so it is probably because you use composer install with --no-dev flag on that environment, and since you are moving the files with rsync probably some of the cache is being synchronized as well, which should not be.

A composer dump-autoload after installing should fix the issue.

fogley

4 years ago

Level 1

You would be correct, I use the --no-dev flag on production.

Just ran composer dump-autoload on both dev and production with no luck after another deployment.

This cache you mentioned, where would I find that?

Nakov

4 years ago

Level 73

@fogley run php artisan config:clear as well.

The cached files should be in storage/framework..

fogley

4 years ago

Level 1

@Nakov

php artisan config:clear on both production and dev machine and deploying again yields the same errors.

BTW, these paths have always been in the rsync exclusion file:

/storage/framework/*/*
/storage/app/*
/storage/logs/*

fogley

4 years ago

Best Answer

Level 1

Solved.

The problem was because the server was running queue:listen as opposed to queue:work. I guess queue:listen relentlessly poked the codebase and revealed that rsync leaves holes when running. It seemed easier when I did it, but as always shortcuts like these ends up biting oneself in the ass.

To make sure that all jobs are up to date, I simply run php artisan queue:restart after deployment.

Please or to participate in this conversation.