Moved from 5.12.13 to .17 and invoices are broken, possibly more. I can view data but if I create a new invoice it gives a non-descriptive server error. Refreshing shows they are there but can’t interact with them. I read some older posts about fixing these errors but its borked no matter what I do. I could clear the pending jobs but the failed jobs stayed the same. Reverted back to the previous snapshot for now.
Ubuntu 24.04
Hi,
If you click “View Last Error” and/or “View Last Queue Error” do you see any details related to the issues?
Saving a new invoice says ‘Something went wrong’ and generates a new invoice each time the save button is hit. Thanks for helping 
Last Queue Error
Illuminate\Queue\MaxAttemptsExceededException: App\Jobs\Ninja\QueueSize has been attempted too many times. in /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/MaxAttemptsExceededException.php:24
Stack trace:
#0 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(794): Illuminate\Queue\MaxAttemptsExceededException::forJob()
#1 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(528): Illuminate\Queue\Worker->maxAttemptsExceededException()
#2 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(431): Illuminate\Queue\Worker->markJobAsFailedIfAlreadyExceedsMaxAttempts()
#3 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(392): Illuminate\Queue\Worker->process()
#4 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(178): Illuminate\Queue\Worker->runJob()
#5 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(149): Illuminate\Queue\Worker->daemon()
#6 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(132): Illuminate\Queue\Console\WorkCommand->runWorker()
#7 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Illuminate\Queue\Console\WorkCommand->handle()
#8 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Container/Util.php(43): Illuminate\Container\BoundMethod::Illuminate\Container{closure}()
#9 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(95): Illuminate\Container\Util::unwrapIfClosure()
#10 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\Container\BoundMethod::callBoundMethod()
#11 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Container/Container.php(696): Illuminate\Container\BoundMethod::call()
#12 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Console/Command.php(213): Illuminate\Container\Container->call()
#13 /usr/share/nginx/invoiceninja/vendor/symfony/console/Command/Command.php(279): Illuminate\Console\Command->execute()
#14 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Console/Command.php(182): Symfony\Component\Console\Command\Command->run()
#15 /usr/share/nginx/invoiceninja/vendor/symfony/console/Application.php(1094): Illuminate\Console\Command->run()
#16 /usr/share/nginx/invoiceninja/vendor/symfony/console/Application.php(342): Symfony\Component\Console\Application->doRunCommand()
#17 /usr/share/nginx/invoiceninja/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun()
#18 /usr/share/nginx/invoiceninja/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(198): Symfony\Component\Console\Application->run()
#19 /usr/share/nginx/invoiceninja/artisan(35): Illuminate\Foundation\Console\Kernel->handle()
#20 {main}
I changed from database to sync and get the following under system health.
[2025-08-17 18:30:36] production.ERROR: Connection refused [tcp://127.0.0.1:6379] {“userId”:1,“exception”:"[object] (Predis\Connection\ConnectionException(code: 111): Connection refused [tcp://127.0.0.1:6379] at /usr/share/nginx/invoiceninja/vendor/predis/predis/src/Connection/AbstractConnection.php:144)
I get the following when creating an invoice on the desktop app.
500: Internal Server Error * Server Error
php artisan queue:clear drops the pending jobs to 0 but still shows failed jobs. Same errors using either interface.
Is the .env file set to use redis? Maybe this info from ChatGPT will help.
That’s a straight Redis connection failure from Laravel (Invoice Ninja uses Redis for cache/queue/session if enabled). Common causes + quick fixes:
Redis isn’t running
sudo systemctl status redis (or service redis-server status)docker compose ps redis (or docker ps | grep redis)Wrong host in Docker (127.0.0.1 problem)
Inside a container, 127.0.0.1 = the app container, not the host or the Redis container. Use the service name (usually redis) instead of 127.0.0.1.
Port/firewall
Redis default is 6379. If you changed it or have a firewall, you’ll see “Connection refused”.
Auth mismatch
If Redis requires a password but .env has REDIS_PASSWORD=null, auth will fail (usually a different error, but worth checking).
Redis crashed / OOM
Look for “OOM”, “RDB/AOF error”, or “Loading” in Redis logs.
Set .env (in the app container) to:
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_PASSWORD=null
REDIS_CLIENT=phpredis
CACHE_DRIVER=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis
Bring Redis up & check logs
docker compose up -d redis
docker compose logs -f redis
Test from the app container
docker compose exec app bash
apt-get update && apt-get install -y redis-tools # if needed
redis-cli -h redis -p 6379 ping
Expect PONG.
Clear Laravel caches (env/config cache can “stick” the old 127.0.0.1):
php artisan config:clear
php artisan cache:clear
php artisan optimize:clear
Restart workers/Horizon if you use them:
php artisan horizon:terminate # Horizon will restart with new config
# or Supervisor:
supervisorctl reread && supervisorctl update && supervisorctl restart all
Ensure Redis is running:
sudo systemctl enable --now redis
redis-cli ping
.env host should be 127.0.0.1 (or your server IP) only if the app and Redis are on the same machine:
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_PASSWORD=null
REDIS_CLIENT=phpredis # if the PHP extension is installed; otherwise use 'predis'
Clear Laravel caches (same commands as above) and restart your PHP-FPM/Nginx if needed.
If Redis is optional in your setup (no Horizon), switch to file/database while you fix Redis:
CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_CONNECTION=database # or 'sync' if you must
Then:
php artisan config:clear && php artisan cache:clear && php artisan optimize:clear
php artisan queue:table && php artisan migrate # if using database queues
Predis\Connection… Connection refused [tcp://127.0.0.1:6379]. In Docker, that host is wrong—use the service name. Outside Docker, it means Redis isn’t listening/running.If you paste your .env Redis lines and confirm whether you’re running Docker or not, I can tailor the exact changes.
Ubuntu 24.04
It’s working now that I installed redis. Can confirm that it wasn’t there before so I dunno what happened to it even though I already had the lines in the .env file. I did add REDIS_CLIENT=predis though. .13 did work without it so maybe I never had it installed? Can’t seem to find it in the installation guides.
Not sure if this is a worry but ‘php artisan queue:clear’ gets rid of pending jobs but it still shows a warning about failed jobs.
Thanks again for your help.
Hi @Hillel,
I wanted to add my experience to this thread as I’ve just spent the better part of a day troubleshooting the exact same issue after updating to v5.12.17.
My Environment:
The Problem: Immediately after the update, I started getting a 500 Internal Server Error when performing any action that triggers a background job (like starting/stopping a task). The laravel.log file was filled with Connection refused [tcp://127.0.0.1:6379] errors, indicating the application was trying to connect to Redis, even though my .env was explicitly set to use the database queue.
Troubleshooting Steps (What Didn’t Work): Like others, I went through an exhaustive process to rule out environmental issues:
.env and storage directory. The error persisted.php artisan optimize:clear multiple times..env file in WHM, cPanel, .htaccess , or the web server’s virtual host configuration. The server was clean, as far as I know from my search for any issues..env Changes: Added SCOUT_DRIVER=null and SCOUT_QUEUE=false to my .env file as suggested. This did not resolve the issue.No matter what I did, the application on v5.12.17 was determined to use Redis for its queue.
The Solution (Workaround): Confirming what the other user found, the only way to resolve the 500 error was to give the application what it wanted:
ea-php84-php-redis extension and enabled it. It’s worth noting that this was a significant chore, as the extension was not available in my WHM EasyApache 4 repositories and had to be compiled from source manually. This new dependency can be a major pain point for self-hosters on similar setups..env file to QUEUE_CONNECTION=redis .After clearing the cache and restarting the web server, the application now works perfectly.
Conclusion: This seems to be a clear breaking change. The application now appears to have a hard dependency on Redis for its queuing system, regardless of the settings in the .env file. For users on environments like Ubuntu + cPanel who don’t have Redis installed by default, this will break their installation upon updating.
Hopefully, this information helps the developers track down the issue. For anyone else experiencing this, installing Redis is the current workaround.
Thanks for the detailed feedback!
cc @david
It is not possible to creat a new task since update from 5.12.16 to 5.12.17:
PHP: 8.4
DB: MySQL 8.4
laravel.log:
“production.ERROR: Connection refused [tcp://127.0.0.1:6379] {“userId”:2,“exception”:”[object] (Predis\Connection\ConnectionException(code: 111): Connection refused [tcp://127.0.0.1:6379] at /html/invoiceninja-5/vendor/predis/predis/src/Connection/AbstractConnection.php:144)
[stacktrace]"
I restored the files from 5.12.16 (without the database) so that I could continue working.
New release with a fix
Supported by Invoice Ninja and Event Schedule