Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fusion ParserCache crashes when generated value is not a FusionFile #4595

Closed
Sebobo opened this issue Oct 12, 2023 · 8 comments
Closed

Fusion ParserCache crashes when generated value is not a FusionFile #4595

Sebobo opened this issue Oct 12, 2023 · 8 comments

Comments

@Sebobo
Copy link
Member

Sebobo commented Oct 12, 2023

In

return $this->cacheForIdentifier($identifier, $generateValueToCache);
the ParserCache just returns a value from another method that can return a mixed value and doesn't check if the value is actually a FusionFile.
That leads to a crash when the generated value is false due to some other issue with the composer state or stale file cache.

@Sebobo
Copy link
Member Author

Sebobo commented Oct 12, 2023

Not 100% sure what would be the correct solution here. Even if the main issue is somewhere else, we have to check the type.

@mhsdesign
Copy link
Member

A little peace offering: #4839

@mhsdesign
Copy link
Member

mhsdesign commented Jan 29, 2024

Is this possibly related? neos/flow-development-collection#3284

Edit sorry no i thought the above happened with redis but seb negated this

@Sebobo
Copy link
Member Author

Sebobo commented Jan 29, 2024

Is this possibly related? neos/flow-development-collection#3284

How and why?

@kitsunet
Copy link
Member

I don't think so, this is a rather special case and should show up as such in the log.

@mhsdesign
Copy link
Member

@kitsunet do you like this fix? #4839

feels a bit weird as on other places we are not that forgiving if the cache is broken and would just crash...

it seems $this->parsePartialsCache->has returns true but $this->parsePartialsCache->get false. Impossible. :D

@kitsunet
Copy link
Member

kitsunet commented Jan 29, 2024

Is why I almost never use "has" in caches, it is never atomic, you cannot know what happens between has and get. I prefer

$cacheEntry = $cache->get(...);
If ($cacheEntry === false)  {
   die(); // early return, exception, whatever
}

mhsdesign added a commit to mhsdesign/neos-development-collection that referenced this issue Feb 2, 2024
> This should not be considered an error. It's a cache, things can happen, it should be able to deal with this.

That's why get will be used directly instead of has.

In the rare edge-case of a fusion dsl returning `false` we cannot cache it anymore.
This is an acceptable compromise.
mhsdesign added a commit to mhsdesign/neos-development-collection that referenced this issue Feb 2, 2024
mhsdesign added a commit to mhsdesign/neos-development-collection that referenced this issue Feb 2, 2024
> This should not be considered an error. It's a cache, things can happen, it should be able to deal with this.

That's why get will be used directly instead of has.

In the rare edge-case of a fusion dsl returning `false` we cannot cache it anymore.
This is an acceptable compromise.
mhsdesign added a commit to mhsdesign/neos-development-collection that referenced this issue Feb 2, 2024
> This should not be considered an error. It's a cache, things can happen, it should be able to deal with this.

That's why get will be used directly instead of has.

In the rare edge-case of a fusion dsl returning `false` we cannot cache it anymore.
This is an acceptable compromise.
@mhsdesign
Copy link
Member

Should be fixed via #4839

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants