What was the rationale behind using filemtime() as part of the hash?

To be sure to have a new file when you update it.
Included in Yii

Since the asset versioning already includes globalAssetsVersion (which is automatically incremented when clearing assets via the admin panel), is filemtime() still necessary?

Yes : when you update a file : it was never reset except if you click on the button.

If we override the behavior to exclude filemtime(), what are the risks?

On a fixed environment : none

Yii : https://github.com/LimeSurvey/LimeSurvey/blob/a7aaf89092a36e98b045344730315144f425cec0/vendor/yiisoft/yii/framework/web/CAssetManager.php#L328

What about changes in theme extension files (like CSS or JS in a theme)?

If we update those files directly (e.g. via deployment), but don't clear the asset cache or increment globalAssetsVersion, wouldn't filemtime() be necessary in that case?
I saw that LimeSurvey has an AssetVersion table in the database which stores extension paths and their versions, but it seems the version is only incremented when clicking "reset" — not when a file is modified.

I saw that LimeSurvey has an AssetVersion table in the database which stores extension

Used (for example) when save theme. Can be updated by plugin, maybe must be when update plugin (after uploadintg).

I understand your POV : but in my opinion: it must be a new feature : disable mtime checking in asset. Strangely: it was not in YII …

This option would be especially useful in stable environments.

filemtime() is useful in development, but in production we can manage versioning via the admin panel (asset clear) or by setting a new 'customassetversionnumber' in config.

Disabling filemtime() would help in distributed systems, where file timestamps can differ across nodes.
We know that we can override the assetManager in the configuration by setting a custom class that extends CAssetManager — just like LimeSurvey does with LSYii_AssetManager, removing mtime. However, after each Limesurvey update, we would have to remember to reapply it.

We know that we can override the assetManager in the configuration by setting a custom class that extends CAssetManager — just like LimeSurvey does with LSYii_AssetManager, removing mtime.

:+1:

However, after each Limesurvey update, we would have to remember to reapply it.

Maybe :
1 put your class out of LimeSurvey directory
2 Load it in your config.php

3. In yoiur config.php : set your own assetManager https://github.com/LimeSurvey/LimeSurvey/blob/a7aaf89092a36e98b045344730315144f425cec0/application/config/internal.php#L148

Unsure, maybe it's possible to do it in a plugin.

Exactly, that’s what we do now.

However, we need to document this as a custom change in LimeSurvey’s change log or upgrade notes to make sure we don’t forget it in the future—especially when upgrading major LimeSurvey versions.

I’m not sure if it can be done as a plugin.

I mitigate this by having shared storage for tmp/assets so nodes in the application layer can serve assets generated by all nodes

Thanks for the suggestion!

The issue is that filemtime() is called on the original asset source files (e.g. from plugins or application modules), not just on the files already copied to tmp/assets. So for shared tmp/assets to work reliably, we’d also need to ensure shared access to all asset sources.

This would require either splitting the application into separately mountable parts or placing the entire application on shared storage, while keeping only configuration local to each node. That’s not optimal for us — especially since the shared disk would also need to be accessible within the load balancer setup.

In practice, we’re back to the original problem: filemtime() would have to be identical across all nodes behind the load balancer for all shared asset sources — which is difficult to guarantee.

That’s why we’re asking if there could be a solution that allows disabling filemtime checks in production environments.

Simplest solution would probably that the load balancer that syncs files also syncs mtimes.

Syncing filemtime across nodes is infeasible in our distributed setup.

We use blue-green deployments behind a load balancer with a split frontend/backend architecture. This means 4 active nodes per deployment, 8 with blue-green. Keeping identical filemtime on all nodes is operationally impractical.

CI/CD pipelines do not preserve modification times, and adding mtime synchronization would overcomplicate deployment.
It is simpler and safer to remove filemtime from the asset hash calculation.

We request an option to disable filemtime usage in hash generation, enabled by default but configurable for setups like ours, where asset reloads always follow customAssetVersionNumber increments.

@2BITS_PL How do you handle uploads?

Maybe tie the use of modification time to debug level? (Don't use for 0, use for >=1)
Or add configuration option to use for development similar to "force_xmlsettings_for_survey_rendering"?

@c_schmitz : move it to feature request ?