I seem to be having trouble with remote config in webgl only. Everything works fine in editor with pushing and pulling and loading the remote config on play. However when ever i build and deploy this to webgl i am getting this issue of “Failed to load config from cache.”
I am doing everything from the documentation and
[Config]Awaiting Remote Fetch
WebGL.framework.js.gz:3:39587
Failed to load config from cache.
Looking into the package itself it seems to be this method firing this:
public void LoadFromCache()
{
try
{
byte[] bodyResult;
using (var reader = File.Open(Path.Combine(Application.persistentDataPath, cacheFile), FileMode.Open))
{
bodyResult = new byte[reader.Length];
reader.Read(bodyResult, 0, (int)reader.Length);
}
var bodyString = Encoding.UTF8.GetString(bodyResult);
var bodyJObject = JObject.Parse(bodyString);
foreach (var kv in bodyJObject)
{
var configType = kv.Key;
if (kv.Value.Type == JTokenType.Object)
{
var cachedConfigResponse = kv.Value.ToObject<ConfigResponse>();
configs[configType] = new RuntimeConfig(configType);
configs[configType].HandleConfigResponse(cachedConfigResponse);
}
}
}
catch
{
Debug.Log("Failed to load config from cache.");
}
}
}
So its unable to receive any cached config data so it kills itself, how would you suggest i fix this?
It could be that checking Application.persistentDataPath does not work well for webGL, as we had similar issues with consoles.
Quick fix would be to avoid caching by removing UNITY_WEBGL from your local code: #if UNITY_EDITOR || UNITY_STANDALONE || UNITY_IOS || UNITY_ANDROID || UNITY_WEBGL
FetchCompleted += SaveCache;
LoadFromCache(); #endif
in ConfigManagerImpl.cs , however in that case, we would bypass caching, so remote config request would work only if there is an internet connection and would not load last cached values.
As we unfortunately do not know exactly why loading from cache fails, this is my suggestion, so please let me know if that would work for you.
Thanks!
Yeah i suspected that peristentDataPath was probably the cause. Couldn’t this be worked around using the indexdb of the browser. Anyways it does seem silly that webgl is supported yet doesn’t function as it should. The whole fetch shouldn’t be dependent on having a cachefile though, you would think if theres no cache file and your connected it would still go ahead and fetch the remote config anyway.
In my case i’m happy to edit and remove the cache as the user needs to be playing online anyway so they can fetch accordingly.
I now have another issue with awaiting remote config. It is known that Tasks don’t really work in webgl so I am wrapping the awaits in uni task however it seems the webrequest in the config manager holds up in isDone while loop. I am getting the response in the browser config with the data successfully but it will never invoke the event because it isn’t reaching that part.
As far as i get is:
Debug.Log($"[ConfigInternal]Awaiting webrequest response");
var requestOp = request.SendWebRequest();
while (!requestOp.isDone)
{
await Task.Delay(1);
}
So its obviously stuck in the while loop, im guessing your suggestion here will be to rewrite all this to use a coroutine webrequest or to use uni task internally in remote config?
If not what is your suggestion?
I am surprised that its marked as supported where it seems each stage of using this has problems or heavy resistance.
Hi @Bigarcade !
It’s amazing that you were able to remotely configure the library to utilize UniTask rather than tasks; please share your solution if you don’t mind!
To your point, we removed Task.Delay() from the runtime package exactly for the reason that it did not translate well for webGL. That was done for the RC Runtime version 3.2.0-pre.1 in Oct 2022.
However, RC package has dependency on the RC Runtime and we updated that dependency for RC >= 4.0.0,
so if you use RC 4.0.0 that Task.Delay() problem should be alleviated.
Again, we apologize for this inconsistency; nonetheless, WebGL was somewhat disregarded as we concentrated more on the mobile platforms, so even if we found issue with Task.Delay, you helped us point to inconsistency with Application.persistentDataPath.
Perusing the forums I see now there is more users with same problem, so we will add this fix in the next release.
The problem with both Tasks & Persistent data path - persists. Is there any upcoming fix for Tasks or should I wrap them with UniTask as well like @Bigarcade suggested ?