kirby icon indicating copy to clipboard operation
kirby copied to clipboard

API cache unlink error

Open findthebug opened this issue 3 years ago • 10 comments

Describe the bug
Strange bug in the api cache, which happens from time to time. I can't figure out what the problem is. My project uses a lot of api caches, which i use inside the template, route or controller. I can just provide screenshots to report the issue, not sure how i can log this? Because the issue is super rare(1 of 100), i can just post what my setup is and the steps to try to reproduce this.

To Reproduce

  1. Setup a basic api cache, like from the cookbook or take this one. this is located in the home template.
$named = "y_day_1";
$apiCache = $kirby->cache('api');
$apiDataSave = $apiCache->get($named);
if ($apiDataSave === null) {
    $query = // whatever you wanna store
    $apiDataSave = $query;
    $apiCache->set($named, $apiDataSave, 720);  // 60 = 1h
}
$yoohExists = $apiDataSave;
?>
  1. On both, first load, and second load the data are loaded/stored properly. In this one i using a 1 day cache time, but this does not matter. I have the same problem with 30min and 1min caches. Not sure yet this error happens if i deactivate the cache time at all.

  2. You can reload the page as many times you like. As long as the data is served via the cache no issues. The problem is, when the cache is expired and you load the page again, so the api has to rebuild the file and cache.

  3. Now, the error happens maybe 1 of 100 times, if step 3 come into play.

  4. Error happens -> Error screen

  5. Cache file are deleted, and rebuild.

  6. Page reload -> Page with new data appears.

  7. Everything works except that kirby displays the message with the unlink.

As far as i can tell, the error has nothing todo with the kind of what you caching or the cache time, it's more about how Kirby is handling the check of unlink the file.

Additional context
Im running all of this inside a vagrant box.

First guess: Maybe it has something todo how vagrant is syncing the files between host and guest system, and when kirby is deleting the new file, vagrant guest is maybe 1ms behind get confused when the unlink is performed? But beside this i have no idea.

Version
Kirby 3.5.0 Vagrant debian / PHP 7.4.8 OSX 10.15.7 Safari and Chrome

Screenshots
1. error_1 2. error_2 3. error_3

1.-> same error but with another api-cache. error_other_one

findthebug avatar Dec 31 '20 10:12 findthebug

Actually F class checks if the file exists before deleting it but I guess the issue might be related to vagrant. I have tested it in a few different ways in my local, the issue does not appear for me 🤔

afbora avatar Dec 31 '20 11:12 afbora

What env do you use to run kirby?

findthebug avatar Dec 31 '20 11:12 findthebug

Kirby 3.5.0

  • Centos 6.9 & PHP 7.3.25
  • Windows 10 & PHP 7.3.14

My guess is the same as yours @findthebug . It is a issue that can occur due to a very small delay (as your said like 1ms) or when there are many instant requests. May be we can handle this error slightly with suppress or empty try/catch block.

afbora avatar Dec 31 '20 12:12 afbora

Is there a way to log this error if i disable debug mode? i have a proper server(not vm) i can test this.

findthebug avatar Dec 31 '20 12:12 findthebug

No, as far as I know 🤔 You can try logging manually?

afbora avatar Dec 31 '20 12:12 afbora

I will try something.

findthebug avatar Jan 01 '21 12:01 findthebug

@findthebug Did you test it?

@lukasbestle How about we suppress all unlinks?

afbora avatar Jan 29 '21 13:01 afbora

Im still try to log this in production. no issues so far and the project is live for 3 weeks now. i think the filesync in vagrant cause the issue. if vagrant filesync is just some mS behind the host filesystem is not up to date and php gets not proper state of the demanded file.

findthebug avatar Jan 29 '21 13:01 findthebug

Then if you want, let's close the issue, if it recurs, let's reopen it, is it okay?

afbora avatar Jan 29 '21 13:01 afbora

Running into this exact problem as well. But reading the flow of the code it makes total sense that the unlink() call can fail when there's two requests simultaneously accessing the same cache value. Simply wrapping the unlink() call in a try { } catch () {} block would fix this?

For now I'm simply wrapping all my cache access in a similar way to work around this problem.

sjaq avatar Jul 29 '22 12:07 sjaq

bastianallgeier avatar Aug 18 '22 08:08 bastianallgeier

Nice thanks!

sjaq avatar Aug 23 '22 15:08 sjaq