Remote Config Returns ConfigOrigin.Remote When Offline with no Cache

Hi.

I am seeing remote config returns ConfigOrigin.Remote when device is offline. Is this normal?

Below is my code and what i am trying to do:

  1. When the device is online, Remote Config would work perfectly and everything is fine.

  2. When the device is online, I delete Remote Config cache with my own code after Remote Config finishes its magic. The reason i do this is to make player harder to cheat.

  3. When the device is offline, Remote Config will not able to read any cache since I always delete that.

  4. When the device is offline, GetData(ConfigResponse configResponse) return ConfigOrigin.Remote, which I would expect it returns .Default since there is no cache and Offline.

If I keep the cache there things would work. But I really want to keep that cache out of the device. Is there a way to tell RemoteConfig to return ConfigOrigin.Default when the device is offline in my case? Or is there a better way to do to what i want to achieve?

Thank you!

using System.Collections;
using UnityEngine;
using Unity.RemoteConfig;
using System.IO;

public class RemoteConfigController : MonoBehaviour
{
     [Tooltip("this delay is mainly for incase there is a loading and saving operations in other scripts so it wait a little bit before reading server")]
     private float startDelay = 0.2f;
     [HideInInspector] public struct UserAttribute { }
     [HideInInspector] public struct AppAttributes { }

     #region Singleton
     public static RemoteConfigController instance;
     private void Awake()
     {
         if (instance != null)
         {
             Destroy(instance.gameObject);
         }
         instance = this;
         DontDestroyOnLoad(this);
     }
     #endregion

     private void Start()
     {
         ConfigManager.FetchCompleted += GetData;
         StartCoroutine(FetchDataCoroutine());
     }

     IEnumerator FetchDataCoroutine()
     {
         yield return new WaitForSeconds(startDelay);
         ConfigManager.SetEnvironmentID("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx");
         ConfigManager.FetchConfigs<UserAttribute, AppAttributes>(new UserAttribute(), new AppAttributes());
     }

     private void GetData(ConfigResponse configResponse)
     {
         switch (configResponse.requestOrigin)
         {
             case ConfigOrigin.Default:
                 Debug.Log("ConfigOrigin = Default.");
                 break;
             case ConfigOrigin.Cached:
                 Debug.Log("ConfigOrigin = Cached.");
                 break;
             case ConfigOrigin.Remote:
                 Debug.Log("ConfigOrigin = Remote.");
                 break;
         }
         StartCoroutine(DeleteRemoteConfigCache());
     }

     IEnumerator DeleteRemoteConfigCache()
     {
         //using delay because the file cannot be deleted at the exact moment after it was created/modified
         yield return new WaitForSeconds(0.1f);
         //check if cache file exist, if so delete the cache file
         string path = Application.persistentDataPath + "/RemoteConfigCache.json";
         if (File.Exists(path))  //check if file exists
         {
             File.Delete(path);
             Debug.Log("Deleted " + path);
         }
     }
}

Hi there!
Thanks for posting on the forums.

When possible could you confirm the version of Remote config you are running? This will help us guide you to a better solution.

We look forward to your response.

Best,
Seb

Thanks for your reply.

I am using RemoteConfig 2.1.2 with Unity 2019.4.37f

Please test with RC 3.0.0-pre.15, this has been addressed in recent releases.

updating works! thank you!

2 Likes

Hey @JeffDUnity3D

I’ve just updated from 2.1.2 to 3.1.3 and noticed the following behaviour…

  1. Device Online
  2. Open Game
  3. FetchConfigs → RemoteSettingsFetched (Origin = Remote, Status = Success)
  4. Exit Game
  5. Device Offline
  6. Open Game
  7. FetchConfigs → RemoteSettingsFetched (Origin = Cached, Status = Failed)

Step 7 might be by design, but doesn’t feel right to me. It implies the cached values failed.

I’m wondering if either of the following scenarios might be better…

  1. FetchConfigs → RemoteSettingsFetched (Origin = Remote, Status = Failed)
  2. FetchConfigs → RemoteSettingsFetched (Origin = Cached, Status = Success)

NOTE: One call, but two events rasied.

Or…

  1. FetchConfigs → RemoteSettingsFetched (Origin = Cached, Status = Success)

Preferably the former as it’s more representative of what actually happened.

Not a deal breaker and it makes no odds to my implementation as I call appConfig.GetX(, ) (regardless of Status) in the event handler (so the defaults are always applied as a fallback)

Just an observation anyway. Hope it makes sense.

We probably don’t want to have two events raised at the same time. Why would you expect both Remote and Cached being called for the same call? If we returned Success every time, there would be no need for the return code. But your point is taken regarding Failed when Cached was indeed “successful” in loading the cached values, I will pass this along.

1 Like

The two events idea was more so the developer is aware that the Remote origin failed. That said, I understand you could argue it’s implied if the Cached or Defaults origin is used so yes, maybe it’s overkill :slight_smile:

But changing the status from Failed to Successful would be good too. Thanks! :slight_smile: