Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Feature Request FetchConfigs synchronously without callback to support MS Extensions.Configuration

Discussion in 'Unity Remote Config' started by Rabadash8820, Aug 21, 2023.

  1. Rabadash8820


    Aug 20, 2015

    It would be great if there was a
    overload that synchronously returned a
    object, rather than relying on a callback.

    Use Case

    I am trying to implement a RemoteConfig configuration provider for the Microsoft.Extensions.Configuration library (installed as a UPM package via UnityNuGet). See the code on GitHub. The MS Configuration library is pretty powerful, and fairly standard in other .NET applications, so it would be great to use RemoteConfig as a configuration source alongside other sources like JSON files, environment variables, command line options, etc.

    Unfortunately, there are some unavoidable issues with a RemoteConfig configuration provider:
    • It cannot load settings by
      ing the
      returned by
      , as this would lead to a deadlock with the Unity main thread
    • It cannot load settings in a
      listener callback after calling
      , as this callback runs at an indeterminate time. The
      constructor could accept a callback and add that as a listener to
      , but that breaks the encapsulation/contract of MS configuration sources. Consumers could also wait for a short time after after building configuration to ensure that
      has been invoked, but the amount of time would be arbitrary--either too short or longer than necessary.
    As such, a RemoteConfig configuration provider can't really be implemented until either:
    1. The Microsoft Configuration system supports building configuration asynchronously (so we could just
      await FetchConfigsAsync
      ), or
    2. Unity RemoteConfig supports synchronous fetching (without a callback)
  2. vd_unity


    Unity Technologies

    Sep 11, 2014
    Hi @Rabadash8820 , thanks for this interesting feature request!

    At this point, we can't really do the web request synchronously without a callback without risking deadlocks.
    It also seems that the lack of async support for Configuration Provider was acknowledged but is unlikely to get support anytime soon according to this thread.

    The one thing which could work for your use case is if the configuration provider returns the cached version of the config synchronously.
    The cached version is available immediately and synchronously, and cca 99% of the time it will be the same as the fetched version.
    In simple terms,
    Code (CSharp):
    1.  RemoteConfigService.Instance.appConfig.config
    will get the values from the cache upon initialization,
    and if the request is successful, both appConfig and cache will be overwritten accordingly.

    If there is a change on the backend, it will be cached correctly upon the fetch and can be accessed at the beginning of the next session in the worst-case scenario.

    Please let us know if this helps, even though is just a workaround suggestion.
  3. Rabadash8820


    Aug 20, 2015
    Hi @vd_unity, thanks for the quick reply! That's interesting, I didn't know
    worked that way. This raises a couple other questions:
    1. Which environments are cached? Is it only the default environment, or all of them?
    2. If the cached configuration is not loaded in time, will
      return an empty array or null?
    3. When does this caching actually take place? Is it during the first accessing of
      or when the RemoteConfig assembly loads? Does that loading block the Unity thread or is it on a background thread?
    4. What is the purpose of ever calling
      then? Is it just for resyncing configuration later, e.g. during a long play session?
    Side note: I think some of this info could be more clearly stated in the docs. Happy to help with this if the docs are open source.
    Last edited: Aug 24, 2023
  4. Rabadash8820


    Aug 20, 2015
    Hey @vd_unity, just wanted to be sure you saw my reply here. Based on your answers on my other thread, I think I can answer #1: the environment cached would be the one passed in
    , or the default environment if none was passed. Is that correct?

    I could still use some insight on the other questions above though. Thanks in advance!