I have a question about flyte caching when running...
# ask-the-community
I have a question about flyte caching when running workflows as standard python functions for example in local testing -- i.e., not by running
pflyte run
from the CLI, but rather just executing the python workflow function directly. In this case, how best to disable caching? I see that work has been done to give
pyflyte run
some local-cache options, but that doesn't apply here. In my codebase, I use a global flag that is typically always on to allow/disallow caching like
Copy code
@task( cache=GLOBAL_CACHING_ENABLED ... )
If I take care to turn this flag OFF in my test module BEFORE the module containing the task is loaded, I can disable caching this way. But it would be nice if there were a more programmatic way to do this that didn't rely as much on order of module loading - just something to say, "hey, flytekit, turn off local caching please!" From the flyte console when "relaunching" a workflow on our k8s cluster, or from code that launches jobs programmatically via FlyteRemote, I can pass an
parameter. Is there some flytekit API I can call to turn off local caching in a similar way? I see reference to
in this PR, but I don't find docs about it. The other option would seem to be executing
pyflyte local-cache clear
in a subprocess during the test, but this feels pretty hacky in a test that's running a very-fast workflow a few times to ensure results are either all different or all the same (which caching gets in the way of). Thoughts? Thanks!
Upon re-reading that PR, it looks to be that one can export
in the testing environment to cause the effect I'm looking for -- no use of local caching. I missed this initially, because I first thought one was required to modify whatever config file holds the config option discussed:
Copy code
Am I reading this correctly? One can disable all use of the local-cache by setting the environment variable? Presumably this will become available in a forthcoming release of flytekit? (I see it was approved 8 hours ago!)
i believe so! and yes, it should become available in the forthcoming release.
cc @Bernhard Stadlbauer
Yes that’s correct! We’re having a similar use case whilst testing and are also aiming to use the environment variable 👍
@Bernhard Stadlbauer Thanks for this work 🙏
I’ve just merged the PR, so the next pre-release should have it