Updating to a new version from .exe causes caching issues

[RobertWesner]

What were you trying to do?

I was attempting to update the version of installed NativePHP software on Windows 11.

What happened?

The Update went well right until the software started. The JS Client fails due to %appdata%\APPNAME\storage being outdated. Deleting the storage folder while the app was closed fixed the issue but expecting administration to manually delete files on end user PCs just to update software is unreasonable.

How to reproduce the bug

1. Create an app with NATIVEPHP_APP_VERSION=1.0.0 and a Bootstrap 5.x frontend.
2. Build with wine32 on Linux
3. Install in Windows VM
4. Update APP to version 1.1.0
5. Install in Windows VM (uninstalling previous does not change the outcome, the %appdata% persists as it should).

Results in: Client side Javascript errors for Bootstrap.

Results in: outdated View. View also links to invalid/outdated Javascript which first made me think it was a JS cache issue. It is a view cache issue.

Package Versions

^0.8.5 -> latest | old version was 0.7.4

PHP Version

^8.3.0

Laravel Version

^11.31

Node Version

latest

Which operating systems have you seen this occur on?

Windows

OS version

Windows 11

Notes

• I will provide you with reproducible binaries within the next few days if the issue is not known.

A simple solution would have the installer force delete %appdata%\APPNAME\storage since it may contain outdated bundled files and views. The storage gets rebuilt automatically on app launch.

The current attempt to hijack bootstrap/app.php to automagically delete storage on version mismatch with a version.txt to compare has failed so far.

[simonhamp]

Are there any errors in the %appdata%\APPNAME\storage\logs\*.log files?

A simple solution would have the installer force delete %appdata%\APPNAME\storage since it may contain outdated bundled files and views.

We can't know whether some of these files are the user's files or whether they're application files. This would need to be up to the application (i.e. your code) to control.

I don't recommend this method - it's too easy for something to go wrong here and lose essential data.

What would be better imo would be to try to understand exactly where it's failing and fixing the root cause.

I suspect this has something to do with caches in the storage directory (storage/framework).

But this is largely dependent on how your specific application behaves.

I'll try to run some arbitrary builds this week to see if I can reproduce, but I may need a copy of your repo to truly understand the problem.

[RobertWesner]

The repository is unfortunately a private company repository. I will attempt to reproduce it tomorrow with the most basic setup. It will cost some time but I have some ideas.

There were no logfiles as no server side errors occured. Client side was missing JS methods.

[RobertWesner]

@simonhamp here are binaries with a very similar issue: view cache being outdated.

https://github.com/RobertWesner/native-win-problems/tree/main

Download: https://www.mediafire.com/file/ts2pod0lrkbnkos/Laravel-1..zip/file

Reproduce:

1. Install 1.0.0
2. It automatically launches
3. Close 1.0.0
4. Install 1.1.0
5. It automatically launches
6. It uses outdated 1.0.0 view
7. Close
8. Delete %appdata%\laravel\storage
9. Start application
10. It rebuilds storage and uses 1.1.0 view with modal

[RobertWesner]

I was able to narrow it down to storage/framework/views.
The following modified bootstrap/app.php works as a temporary fix by clearing said folder.

In my opinion, the views folder should be emptied on install/update if it exists. It gets rebuilt automatically. No user files should be affected by this.

<?php

use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;

// FIX VERSION CACHE PROBLEM>>>
if (defined('PHP_WINDOWS_VERSION_MAJOR')) {
    (function () {
        $appData = env('APPDATA');
        if ($appData) {
            $env = Dotenv\Dotenv::createArrayBacked(__DIR__ . '/../')->load();
            $projectAppData = $appData . '/' . strtolower($env['APP_NAME']);
            $versionFile = $projectAppData . '/version.txt';
            $nativeAppVersion = $env['NATIVEPHP_APP_VERSION'];

            if (!file_exists($versionFile) || file_get_contents($versionFile) !== $nativeAppVersion) {
                $call = function ($recursive, string $path): void
                {
                    if (is_dir($path)) {
                        foreach (array_diff(scandir($path), ['.', '..']) as $file) {
                            $recursive($recursive, $path . '/' . $file);
                        }
                    } else {
                        unlink($path);
                    }
                };
                $call($call, $projectAppData . '/storage/framework/views');
                file_put_contents($versionFile, $nativeAppVersion);
            }
        }
    })();
}
// <<<FIX VERSION CACHE PROBLEM

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        //
    })
    ->withExceptions(function (Exceptions $exceptions) {
        //
    })->create();

[RobertWesner]

@simonhamp were you able to reproduce it? It would be great to not rely on a hack to clear cache. Are there plans on how to move forward with this issue?

[simonhamp]

I think the right solution here is for us to explicitly rebuild the view cache when we detect the updated version has been installed, i.e. by running php artisan view:cache on boot up

[simonhamp]

This is coming.