Problems using @cache.action(valid_statuses=[200])

[Lisandro]

I'm having trouble to avoid caching pages that returned anything else than HTTP 200.

Consider the following simple example:

@cache.action(time_expire=300, cache_model=cache.redis, session=False, vars=False, public=True, valid_statuses=[200])
def index():
    raise HTTP(503)

When I hit the URL the first time, I can see in deed a 503 response status (I checked headers with Chrome Inspector), and there is nothing cached (I checked redis stored keys).

But the second time I hit the URL, the server returns an HTTP 200 with an empty body, and it keeps returning HTTP 200 for the 5 minutes (time_expire=300).

After that time, I hit the URL again, and I can see the HTTP 500. 

What am I missing?

[Dave S]

As a WAG (I dunno the cache manipulators), your "valid_statuses" is setting the status to be returned when the page is served from cache.

 /dps

[Anthony]

Looks like a bug in the Redis cache implementation. cache.action first saves the output to the cache, and later if it is determined that the HTTP status is not valid, it then attempts to delete the output from the cache via cache_model(cache_key, None). Passing None as the second argument to one of the cache models is supposed to delete the key, but this does not work with Redis -- see https://github.com/web2py/web2py/blob/R-2.14.6/gluon/contrib/redis_cache.py#L152. In the Redis cache client, setting the f argument to None only deletes the key if the object wasn't found in the cache or has expired. We should probably change the Redis cache to match the behavior of the other cache models.

Anthony

[Anthony]

On Thursday, June 9, 2016 at 2:46:27 PM UTC-4, Dave S wrote:

As a WAG (I dunno the cache manipulators), your "valid_statuses" is setting the status to be returned when the page is served from cache.

No, he's using valid_statuses correctly -- the output is cached only when the status matches one of those in the valid_statuses list. Actually, it is unnecessary to list 200, because by default, only statuses beginning with 1, 2, or 3 are considered valid.

Anthony

[Anthony]

Just submitted an issue: https://github.com/web2py/web2py/issues/1355

[Lisandro]

Sorry to bother in this old thread, but I've noticed that the last stable version of web2py doesn't include the fix that was made previously to correct this bug.

I'm trying with last version: 2.14.6-stable+timestamp.2016.05.10.00.21.47 but the bug is there.

I checked the source code of gluon/contrib/redis_cache.py and I noticed that the fix isn't there. 

The issue had been reported here: https://github.com/web2py/web2py/issues/1355

And the fix was this: https://github.com/web2py/web2py/commit/a96f137e034c0238f832f8bc6bf34a52d8973e66

I've tried applying that fix over the current version, but I don't think it solves the problem: the function now does return 503, but it takes about 10 seconds to respond, and I can see that with every request I made to the function, a new key is added to the cache. Should the issue be re-opened?