You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
there is a nasty regression in the last Neos bugfix release with the Fusion Parser in connection with FileMonitor / local dev mode.
The following happens:
Should: Neos Fusion file change leads to correct re-rendering of the page
Actual: Old code state is rendered, even after Flow has recognised a FileMonitor change
Setup:
We have a site package that is located under ./DistributionPackages/Customer.Site
here we change the fusion files
Debugging:
Observation: the cache for Neos_Fusion_ParsePartials is not invalidated correctly
when initially caching the parsed fusion file the file path ./DistributionPackages/Customer.Site/.../MyFusion.fusion is converted to an md5 as identifier
on cache invalidation the flow file monitor returns a file path like ./Packages/Sites/Customer.Site/.../MyFusion.fusion which converted to an md5 as identifier
the cache flushing is thus not possible as the flow file monitor returns the symlinked path, while fusion operates on actual files.
The symlink has to be resolved consistently in both places (write cache file, invalidate cache file) but that is not always possible when flow for example informs that a file has been deleted. Calling realpath here would just return false and if not correctly handled will resurface the bug that was initially trying to be solved: #4415
Fix flows file monitor to operate on actual files and not symlinks (hard)
Revert the previous change and just silently ignore if a file was removed and keep the cache artefact, which would lead to additional cache entries that are never flushed, and might lead to stale caches if a files is removed then added and changed without flow detecting it.
Replaces #4509Resolves#4415
After deleting a fusion file like `BrandLogo.fusion` one will face the error after booting flow and thus triggering the file monitor and its listeners: (even like a simple `flow help`)
```
Couldn't resolve realpath for: '/absolutePath/Code/core/Neos.NeosIo/Packages/Sites/Neos.NeosIo/Resources/Private/Fusion/Content/BrandLogo/BrandLogo.fusion'
```
This is caused as `realpath` returns false if the file was deleted, and we were to eager validating this. But as flows file monitor already returns absolute paths we can skip the realpath calculation here and move it to the `ParserCache::cacheForFusionFile`.
Initially the call to `realpath` was made in a single place to avoid making to many assumptions about the form flow returned file paths.
there is a nasty regression in the last Neos bugfix release with the Fusion Parser in connection with FileMonitor / local dev mode.
The following happens:
Should: Neos Fusion file change leads to correct re-rendering of the page
Actual: Old code state is rendered, even after Flow has recognised a FileMonitor change
Setup:
./DistributionPackages/Customer.Site
Debugging:
Neos_Fusion_ParsePartials
is not invalidated correctly./DistributionPackages/Customer.Site/.../MyFusion.fusion
is converted to an md5 as identifier./Packages/Sites/Customer.Site/.../MyFusion.fusion
which converted to an md5 as identifierThe symlink has to be resolved consistently in both places (write cache file, invalidate cache file) but that is not always possible when flow for example informs that a file has been deleted. Calling
realpath
here would just returnfalse
and if not correctly handled will resurface the bug that was initially trying to be solved: #4415Regression due to the mentioned fix: #4838
Possible solutions:
Affected Neos Versions:
Neos 8.0.17
Neos 8.1.12
Neos 8.2.12
Neos 8.3.10
Thanks for reporting this bug and investigating
@patrickreck @nezaniel @erickloss @lorenzulrich
Slack thread: https://neos-project.slack.com/archives/C050C8FEK/p1708954764784039
The text was updated successfully, but these errors were encountered: