Flyte enables production-grade orchestration for machine learning workflows and data processing created to accelerate local workflows to production.

Flyte

Hello. I have noticed that in Flyte 2, when one runs `flyte delete secret &lt;SECRET_NAME&gt;` the secret is not actually deleted and is cached for 24 hours.
Even if you run `flyte create secret &lt;SECRET_NAME&gt;` and set a new value, the old value of `&lt;SECRET_NAME&gt;` will not be overridden. Is this expected behavior?

According to Claude:
&gt; *The secret value is cached with a 24h TTL, and delete does not evict it.* This is the real reason the pod execution is _still working_ after your delete:
&gt; • The pod mutator/webhook resolves secrets via`EmbeddedSecretManagerInjector.lookUpSecret`(`embedded_secret_manager.go:114`). It *checks an in-memory cache first*, only hitting the fetchers on a miss.
&gt; • That cache comes from`flytestdlib/cache`, whose default `DefaultExpiration` is *24 hours* (`config.go:30-31`).
&gt; • `flyte delete secret` goes to a _different_ process — the secret service (`secret/service/secret_service.goDeleteSecret`), which only does `k8sClient.Delete(...)` on the backing k8s Secret. There is *no cache-invalidation signal* to the webhook. So any run within 24h of a prior successful fetch keeps getting the cached credential.

It’s known issue. we will add cache invalidation