Option to fail quickly instead of blocking when initial generation is happening?

Migrated issue, originally created by Marc Abramowitz (msabramo)

Current behavior is that if the cache key is empty or invalidated, the first worker will start regenerating and other workers will block until the first worker releases the dogpile lock. (for an expired key, the workers don't block; they return the expired value).

I'm wondering if it makes sense to have an option to make the workers fail quickly instead of blocking. I hate to tie up Python workers that are just waiting for a lock.

I'm doing it in app code now by essentially doing a get and checking for NO_VALUE and if NO_VALUE is there, I call set with a little busy error response and then call the original function and then cache the value that comes back from it. So the first worker will go through this and will set the little busy error response so that other workers will see that until the regen is complete and the new value is cached.

I'm wondering if a pattern like this could be put in dogpile.cache?

I'd be willing to take a stab at a PR. I just want to make sure it's something that you might be interested in before I start coding. Or maybe there is already an even easier pattern to do this?

Start by reading the cache-key regeneration and dogpile-lock behavior described in the issue, including how get, NO_VALUE, and set interact during initial generation. Define the desired fail-fast option and its behavior for waiting workers, then confirm the approach with maintainers before identifying implementation and test locations.