Any scenarios when configResponse.requestOrigin is NOT ConfigOrigin.Remote?

We've just noticed that in our released app we haven't even implemented the cases ConfigOrigin.Default and ConfigOrigin.Cached in our FetchCompleted callback.

In our code you can only proceed to start the game if remote config returns ConfigOrigin.Remote. This was unintended and we're worried if this would block some users from playing but so far, surprisingly, even in flight mode without network we always reach the ConfigOrigin.Remote case and the game starts fine.

So we've probably misunderstood this, we thought it would used cached values if, for example due to no internet, it cannot reach the remote server. But this is not true apparently.

So under what circumstances would it happen, if ever, that case ConfigOrigin.Remote is not true?

Here is the snippet from the Remote Config sample code that I'm referring to:

Code (CSharp):

1. void ApplyRemoteSettings (ConfigResponse configResponse) {
2.        // Conditionally update settings, depending on the response's origin:
3.        switch (configResponse.requestOrigin) {
4.            case ConfigOrigin.Default:
5.                Debug.Log ("No settings loaded this session; using default values.");
6.                break;
7.            case ConfigOrigin.Cached:
8.                Debug.Log ("No settings loaded this session; using cached values from a previous session.");
9.                break;
10.            case ConfigOrigin.Remote:
11.                Debug.Log ("New settings loaded this session; update values accordingly.");

@JeffDUnity3D
@markychoi

 

Thank you for your reply. No we didn't mean to require remote we just forgot to implement the other two cases and released a version like that but seeing that it'll route it to the remote case either way we won't even have to push a fix so great then. And the cached value is a great thing!
Everything alright than.