-
Notifications
You must be signed in to change notification settings - Fork 216
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
Fix mkdir race condition in FileSystemCacheHandler #375
Conversation
@B-Galati - I appreciate the contribution here! We're actually working on a major release for this library and one part of that will be re-implementing the caching that we use in either PSR-6 (#282) or PSR-16. This will mean that this cache driver will go away. I'll close this for now but if we get more feedback that this would be good to have ahead of that release, we'll consider a patch release for it. Thanks again! |
@jose-e-rodriguez thanks. Would you know when do you plan to release this new major? I cannot see any active development on the repo for a new major :/ Preparing a new major release does not mean the current or previous one should not be fixed, that's a pitty. |
We don't have any concrete dates but we just merged our first PR towards that here: https://github.com/auth0/auth0-PHP/tree/7.0.0-dev I would guess in the next month or so.
I totally agree, we'll provide support for the 5.x.x version for a while. Your PR says that that isn't a big deal so I figured it would be fine to close it with an explanation. Is this something you need in the SDK within the next month or so? |
@joshcanhelp Thanks again for these info!
You are right. I meant that it's not a big deal in the sense of which it's a minor bug that should not prevent an application from working as expected. IMHO it worth it to release it within a month.
Nothing urgent but I would love to have that fix whenever it's possible to prevent Sentry reminding me this bug from time to time. Another thing is that I don't know how hard it will be to upgrade to the new major and I don't think I will be able to prioritize a migration as soon as the new major is released. |
Understood and thanks for the additional clarification. I'll re-open this and take a look this week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A fix and a question.
Also ... it does not seem like this solves your issue. Why would you be getting a File exists
error for a mkdir()
call right after you check for its existence?
if (! file_exists($this->tmp_dir)) { | ||
mkdir($this->tmp_dir); | ||
if (! is_dir($this->tmp_dir) && ! @mkdir($this->tmp_dir, 0777, true) && ! is_dir($this->tmp_dir) ) { | ||
throw new \RuntimeException("Cache Handler was not able to create directory '$this->tmp_dir'"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure we want to throw an exception here? Seems like we shouldn't fail the application if cache isn't running. Also, if we're increasing from a warning/notice that can be hidden/logged to a potential exception, that has the potential to break folks on a patch/minor upgrade.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, IMHO it sounds like a big problem to have a failing cache system and not being aware that it does not work.
Also, if we're increasing from a warning/notice that can be hidden/logged to a potential exception, that has the potential to break folks on a patch/minor upgrade.
At the moment the set
method of the cache handler would fail if the tmp directory does not exist so it should not change anything for the next version. On the other hand, with this PR it would not create false positive warning for a non existent directory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment the set method of the cache handler would fail
It would fail but it would be a warning, not a fatal or exception:
https://www.php.net/manual/en/function.fopen.php
I agree that a failing cache system is a problem and, in this case, since it's not something that runs on every load, it's probably best to stop the process. But we can't introduce an exception here in a minor or patch release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment the set method of the cache handler would fail
It would fail but it would be a warning, not a fatal or exception:
Indeed! Thank you :-)
I agree that a failing cache system is a problem and, in this case, since it's not something that runs on every load, it's probably best to stop the process. But we can't introduce an exception here in a minor or patch release.
That is not a documented and should be catched exception. That is only a safe guard in case something is wrong that the user should be aware of. A bit like a NullPointerException
or IndexOufOfBoundException
that would be thrown by the runtime himself.
Because it's a quite hard to reproduce race condition issue. See https://github.com/kalessil/phpinspectionsea/blob/master/docs/probable-bugs.md#mkdir-race-condition. After checking this link I looked at how Symfony/Doctrine/etc. deal with that kind of race condition and then come up with this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for sticking with me on this @B-Galati !
if (! file_exists($this->tmp_dir)) { | ||
mkdir($this->tmp_dir); | ||
if (! is_dir($this->tmp_dir) && ! @mkdir($this->tmp_dir, 0777, true) && ! is_dir($this->tmp_dir) ) { | ||
throw new \RuntimeException("Cache Handler was not able to create directory '$this->tmp_dir'"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment the set method of the cache handler would fail
It would fail but it would be a warning, not a fatal or exception:
https://www.php.net/manual/en/function.fopen.php
I agree that a failing cache system is a problem and, in this case, since it's not something that runs on every load, it's probably best to stop the process. But we can't introduce an exception here in a minor or patch release.
@B-Galati - Apologies for the long pause here. I'd like to get this merged into the master branch for 5.6 but I think an exception, even if warranted, should not be added in a minor release. I think it's important enough to stop application startup but if an existing application has this misconfigured and not caching but still running fine, then a minor update will crash it immediately. Since we're going to change how this works in the major (use a standard interface, discussed in #282 if you want to chime in), I think replacing the exception with a |
@joshcanhelp done :-) |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Changes
From time I am having errors such as
Warning: mkdir(): File exists
coming fromFileSystemCacheHandler
.Not a big a deal but it's creating false positive alerts.
References
Testing
Quite hard to test but it's a known issue. Most framework for example are using that approach.
This change adds test coverage
This change has been tested on the latest version of PHP
Checklist
I have read the Auth0 general contribution guidelines.
I have read the Auth0 Code of Conduct.
All existing and new tests complete without errors.
The correct base branch is being used.