1. Action Definition
   
   • Open your project on the Kuika platform.

• Click the Add Action button on the right side and select the Check Key Existence action.

2. Cache Key Determination

• Select the key you want to check. This key must have been added previously with Push To Cache.
• Example: user_123_filters

3. Using the Cache Provider
   
   • Must be the same as the cache provider where the key is located (InMemory, Redis, Mongo, or SQL).
4. Running and Testing the Action
   
   • Run the action in Preview mode.
   • As output, you can verify whether the key is in the cache.
   • If you are using Redis, you can check the existence of the key via the terminal with redis-cli -h localhost -p 6379.

Important Points

• The Check Key Existence action is only valid for keys added with Push To Cache or already existing in the cache.
• When InMemory is selected, the key will be lost because the values will be deleted when the application is closed.
• If the key is not found, the action may return false or an error; it is important to add conditions accordingly in subsequent actions.

In an e-commerce application, the user has saved product filters with Push To Cache. Before the user applies the filters, the Check Key Existence action checks whether the filters are in the cache. This ensures that the Fetch From Cache or Remove From Cache actions only work with valid keys.

Step-by-step usage

• Filter Key Check
  
  • When the user arrives at the product list page, the system checks whether the user_123_filters key is in the cache with Check Key Existence.
• Running the Check Key Existence Action
  
  • It is added as an OnClick action to the page load or button click event.
• Parameters
  
  • Cache Key: user_123_filters
• Next Actions
  
  • If the key does not exist: A warning such as “Save filters first” can be displayed to the user, or default values can be applied.
• Testing and Validation
  
  • Web: The existence of the key is verified with the EXISTS user_123_filters command in Redis CLI.
  • Mobile: The existence or absence of the key is tested in InMemory cache preview mode.

• Conditional Check: The existence of the key can be checked based on specific user roles, screen states, or application states. For example, only certain keys can be verified for admin users.
• Expiration Dynamics: When checking the existence of the key, the expiration time can be taken into account dynamically; for example, keys that have expired can be ignored.
• Default Value Assignment: If the Key is not found in the Key Cache, a default value can be assigned to the variable to be used after the action, or fallback actions can be triggered.
• Output Type Control: If the Key is present, you can ensure that the returned data type is compatible with downstream actions.

Technical Risks

• Incorrect Key Usage: Incorrect or invalid key usage in the Check Key Existence action can cause errors in downstream actions.
• InMemory Limitations: When using InMemory cache, keys will be lost when the application closes, which may result in checks based on incorrect assumptions.
• Connection String Errors: An incorrect Redis, Mongo, or SQL connection string may cause the action to fail.
• Expiration Errors: Incorrectly set expiration times may cause keys to be deleted earlier than expected or held for an unnecessarily long time.
• Beta Behavior: Some behaviors related to Redis or other providers may differ between test and preview environments.