500 Server Error after pulling new image

[RobertD502]

Describe the bug
As of lately, whenever an updated image is pulled (from the latest branch), navigating to the container returns a 500 server error:

The only way to get around this issue is to manually restart the container after an updated image has been pulled/the container has started.

To Reproduce
Steps to reproduce the behavior:

1. docker compose pull && docker compose up -d to pull and deploy updated image
2. Once up, navigate to the container in any browser, which returns the 500 server error
3. docker restart speedtest to restart the container after which the login screen appears as expected

Expected behavior
A clear and concise description of what you expected to happen.

Environment (please complete the following information):

• OS: Ubuntu 22.04.3 LTS
• Architecture: amd64
• Browser Edge chromium
• Version: Speedtest-Tracker 0.13.0 (App version)

Screenshots

Logs

192.168.1.33 - - [03/Oct/2023:16:08:52 +0000] "GET / HTTP/1.1" 500 6622 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36 Edg/117.0.2045.47"
[2023-10-03 16:08:52] production.ERROR: No application encryption key has been specified. {"exception":"[object] (Illuminate\\Encryption\\MissingAppKeyException(code: 0): No application encryption key has been specified. at /var/www/html/vendor/laravel/framework/src/Illuminate/Encryption/EncryptionServiceProvider.php:79)
[stacktrace]
#0 /var/www/html/vendor/laravel/framework/src/Illuminate/Support/helpers.php(307): Illuminate\\Encryption\\EncryptionServiceProvider->Illuminate\\Encryption\\{closure}()
#1 /var/www/html/vendor/laravel/framework/src/Illuminate/Encryption/EncryptionServiceProvider.php(77): tap()
#2 /var/www/html/vendor/laravel/framework/src/Illuminate/Encryption/EncryptionServiceProvider.php(60): Illuminate\\Encryption\\EncryptionServiceProvider->key()
#3 /var/www/html/vendor/laravel/framework/src/Illuminate/Encryption/EncryptionServiceProvider.php(32): Illuminate\\Encryption\\EncryptionServiceProvider->parseKey()
#4 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(908): Illuminate\\Encryption\\EncryptionServiceProvider->Illuminate\\Encryption\\{closure}()
#5 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(795): Illuminate\\Container\\Container->build()
#6 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(937): Illuminate\\Container\\Container->resolve()
#7 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(731): Illuminate\\Foundation\\Application->resolve()
#8 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(922): Illuminate\\Container\\Container->make()
#9 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(1066): Illuminate\\Foundation\\Application->make()
#10 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(982): Illuminate\\Container\\Container->resolveClass()
#11 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(943): Illuminate\\Container\\Container->resolveDependencies()
#12 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(795): Illuminate\\Container\\Container->build()
#13 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(937): Illuminate\\Container\\Container->resolve()
#14 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(731): Illuminate\\Foundation\\Application->resolve()
#15 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(922): Illuminate\\Container\\Container->make()
#16 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(255): Illuminate\\Foundation\\Application->make()
#17 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(213): Illuminate\\Foundation\\Http\\Kernel->terminateMiddleware()
#18 /var/www/html/public/index.php(55): Illuminate\\Foundation\\Http\\Kernel->terminate()
#19 {main}
"} 

Additional context
Add any other context about the problem here.

[RobertD502]

I'm assuming since I don't have a persisted key, this issue is coming up whenever a new image is pulled. I'll set one now and will see if the same happens with the next update.

[alexjustesen]

Feel free to close this out should that fix the issue

[RobertD502]

Since, according to the documentation, this ENV variable isn't required (with a key being generated by default), could this be a cache issue when a new image is pulled: should the docker image reset the cached config after generating a new key (for those that don't have a key set) with the command php artisan config:cache following the key generation command?

[alexjustesen]

Try running php artisan optimize:clear in the container and then restart it. It's probably in the wrong order.

[RobertD502]

I thought perhaps when a new image is pulled the cache would need to be cleared for those that don't have APP_KEY defined within this function.

[alexjustesen]

So that command isn't actually used in startup and is intended to either create a fresh local instance or should someone want to completely refresh their deployed application.

The startup script is actually here and has a different section for the app key.

[RobertD502]

My apologies for linking to the wrong file.

An update: I have another remote system that I hadn't updated to 0.13.0 yet, so I was able to use it as a test. I entered into the container, generated a key, and then set the APP_KEY to it. I then pulled the updated image and sure enough no 500 error. So, it looks like the key is the root cause of the 500 error when updating the image for users that don't have the APP_KEY set.

[alexjustesen]

Cool thanks for confirming, I'm going to tag this as a bug and get the caching order fixed.

[RobertD502]

Appreciate the quick response!

[alexjustesen]

@RobertD502 pipeline is building v0.13.1 now and the cache will be fixed in that release. Also you should see a significant page performance as the cache default has been changed to the file driver.

All changes in #841 with a link to the docs.

[RobertD502]

@alexjustesen
Did not seem to get fixed:

I commented out the APP_KEY prior to pulling the latest image. Once it was pulled and the container was running, navigating to it still results in a 500 error. Should the cache be cleared after the new key is generated? The threads I've seen about this issue usually involve resetting the cache after key is generated.