Upload Stuck Due to Cache Corruption

Issue: Upload Stuck Due to Cache Corruption

If you are experiencing issues uploading an agent or package, it may be caused by a degraded or corrupted cache. To resolve this, you can manually inspect and clean the cache entries.

Identify the Environment

First, determine which environment the issue is occurring in:

Use the test/ path if the problem occurs during testing.
Use the prod/ path if the issue happens during production uploads.

Option 1: Using RedisInsight (Graphical Interface)

If you have access to RedisInsight, follow these steps to clear the cache:

Access Valkey (Redis): Ensure you can connect to Valkey in your environment. Port-forwarding may be necessary to establish the connection.
Retrieve the Password: Obtain the Valkey password from your Kubernetes secret. You can typically do this by executing a command similar to:
```
echo $(kubectl get secret --namespace unoagentic valkey-password-secret -o jsonpath="{.data.password}" | base64 -d)
```
Connect with RedisInsight: Use the retrieved password to connect to your Valkey instance via the RedisInsight application.
Navigate to the Relevant Key Namespace: Once connected, navigate to the specific key namespace corresponding to your environment and pod.
1. For testing: test/<POD-NAME> (Example: test/unoaiagenticbuilder-agentic-runner-test-0)
2. For production: prod/<POD-NAME> (Example: prod/unoaiagenticbuilder-agentic-runner-prod-0)
Delete all keys: Delete all keys located under the identified relevant folder/namespace.

Option 2: Using CLI (Command Line Interface)

If you are using only the command-line interface, follow these steps to clear the cache:

Export the Valkey Password: Set an environment variable for the Valkey password:
```
export VALKEY_PASSWORD=$(kubectl get secret --namespace <namespace> <secret-name> -o jsonpath="{.data.password}" | base64 -d)
```
- Replace <namespace> with your Kubernetes namespace and <secret-name> with the actual name of your Valkey password secret.
Launch a Temporary Valkey Client Pod: Run a temporary pod with the Valkey CLI client to connect to your Valkey instance:
```
kubectl run --namespace <namespace> -it --rm valkey-client --restart='Never' \
 --env VALKEY_PASSWORD=$VALKEY_PASSWORD \
--image docker.io/bitnami/valkey:8.1.2-debian-12-r0 \
--command -- bash
```
- Replace <namespace> with your Kubernetes namespace.
Connect to Valkey: Inside the temporary client pod, connect to Valkey using the CLI:
```
 REDISCLI_AUTH="$VALKEY_PASSWORD" valkey-cli -h valkey-primary
```
Clear the Cache: Choose One of the Following Methods
1. Option A -Use FLUSHALL (if enabled):
  FLUSHALL
  1. Caution: This command will delete all keys in the entire Valkey instance, across all environments. Use this method with extreme caution and only if you fully understand its implications.
2. Option B - Manually Delete Environment-Specific Keys:
  1. List keys in the target environment: Identify the keys specific to your problematic environment.
    - For testing: KEYS test:<POD-NAME>*
    - For production: KEYS prod:<POD-NAME>*
    - Example: KEYS prod:unoaiagenticbuilder-agentic-runner-prod-0*
  2. Delete the identified keys: Use the DEL command for each key or a script to automate deletion of the listed keys.