Skip to content

SERIOUS BUG IN NEW VERSION #557

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

Closed
GrahamCampbell opened this issue Mar 31, 2017 · 11 comments · Fixed by #558
Closed

SERIOUS BUG IN NEW VERSION #557

GrahamCampbell opened this issue Mar 31, 2017 · 11 comments · Fixed by #558

Comments

@GrahamCampbell
Copy link
Contributor

Requests are being cached incorrectly, so that API calls to get a users repo are now returning cached results from the wrong user. I am rolling back to the previous version immediately.

@acrobat
Copy link
Collaborator

acrobat commented Mar 31, 2017

I think the generated cache key is to general. See https://github.com/php-http/cache-plugin/blob/master/src/CachePlugin.php#L290

If the request parameters are included the key will be unique enough I think

Thoughts on this @Nyholm?

@GrahamCampbell
Copy link
Contributor Author

This is only in the very latest update. No such bug occurred 7 days ago.

@acrobat
Copy link
Collaborator

acrobat commented Mar 31, 2017

That's because the caching of requests was broken in previous versions. All requests with the private or no-cache directive were skipped by the cache plugin. So no github api request could be cached

You can fix this for now by passing this option to the cache plugin. Example from the docs:

use Cache\Adapter\Redis\RedisCachePool;

$client = new \Redis();
$client->connect('127.0.0.1', 6379);
// Create a PSR6 cache pool
$pool = new RedisCachePool($client);

$client = new \Github\Client();
$option = [ 'respect_response_cache_directives' => ['no-cache', 'private', 'max-age', 'no-store']];
$client->addCache($pool, $options);

@acrobat
Copy link
Collaborator

acrobat commented Mar 31, 2017

@GrahamCampbell Can you provide some example call which fails when using the cache? So I can check how to fix this

@Nyholm
Copy link
Collaborator

Nyholm commented Mar 31, 2017

Thank you for reporting this. I will make a PR.

@Nyholm
Copy link
Collaborator

Nyholm commented Apr 5, 2017

I've added #558. Please review it.

We are just waiting for a new tag on the CachePlugin.

@GrahamCampbell
Copy link
Contributor Author

Also, the current version of this package is throwing a deprecation error, even know I'm not using a deprecated feature?

@GrahamCampbell
Copy link
Contributor Author

@Nyholm
Copy link
Collaborator

Nyholm commented Apr 5, 2017

Also, the current version of this package is throwing a deprecation error, even know I'm not using a deprecated feature?

From where?

@GrahamCampbell
Copy link
Contributor Author

GrahamCampbell commented Apr 5, 2017

It's because you set a deprecated default: https://github.com/php-http/cache-plugin/blob/v1.3.0/src/CachePlugin.php#L336.

@GrahamCampbell
Copy link
Contributor Author

Surely this still won't fix everything. Shouldn't the caching have only been etag based, why on earth would we provide a correct etag, and then fetch the wrong cache response?

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 a pull request may close this issue.

3 participants