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

make sure we only use the cache if write was successful #82

Merged
merged 2 commits into from
Sep 17, 2019
Merged

make sure we only use the cache if write was successful #82

merged 2 commits into from
Sep 17, 2019

Conversation

dbu
Copy link
Contributor

@dbu dbu commented Sep 17, 2019

Q A
Bug fix? yes
New feature? no
Doc updated no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT

I don't know how to test this, as those things normally don't fail. (Most likely offender would be out of disk space...). But i did validate with a 😃 in the TestObject that utf8 in code does not break the strlen vs bytes written.

See also #81 for when the data already is written or a disk is corrupted later on.

// we did not write all characters, or completely failed to write.
@unlink($tmpFile);

return;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on other failures, this class throws exceptions. being a cache, i would expect it to continue silently, as cache problems should not break the application. if you prefer, i can change this to an exception to be more consistent with the behaviour of the rest of the cache implementation.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be a very bad situation but I guess it makes sense to cover this case...

When the disk is out of space... a lot of other bad things could happen...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed so. we don't maintain the servers themselves and when we checked, there was ample disk space available. but with enough writes, one might fail for some reason somewhere, and in our case it left us with this half-written cache that broke everything (on one of several nodes only, so it looked like the error only happens randomly...)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright. I guess this is pretty hard to test, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the happy case is tested, but failure is difficult to test. maybe with stream wrappers and whatnot, but stream wrapper is so fragile that it randomly breaks other things too.

@dbu
Copy link
Contributor Author

dbu commented Sep 17, 2019

how do you feel about merging this as it is now? would that be ok or do we need more tests? and do you plan a patch release after these improvements and fixes? there are a few other tweaks since 2.0.0 2.0.0...master

@goetas goetas merged commit 8d89581 into schmittjoh:master Sep 17, 2019
@goetas
Copy link
Collaborator

goetas commented Sep 17, 2019

This is ok for me!

Will do a patch release soon! will have to put it in my agenda !

@goetas
Copy link
Collaborator

goetas commented Sep 18, 2019

@dbu
Copy link
Contributor Author

dbu commented Sep 18, 2019

thanks a lot!

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

Successfully merging this pull request may close these issues.

None yet

2 participants