"Most recently fetched config is already activated" after remote config activate() call

[b-onc]

[REQUIRED] Step 2: Describe your environment

• Xcode version: 10.3
• Firebase SDK version: 6.6.0
• Firebase Component: Remote Config
• Component version: 4.2.1

[REQUIRED] Step 3: Describe the problem

We fetch and activate remote config with the following code:

let expirationDuration: TimeInterval
#if DEBUG
expirationDuration = 0
#else
expirationDuration = 3600
#endif
firebaseRemoteConfig.fetch(withExpirationDuration: expirationDuration) { [unowned self] (status, error) in
    if status == .success {
        log.info("Remote Config fetched")
        self.firebaseRemoteConfig.activate(completionHandler: { (error) in
            if let error = error {
                log.error(error)
            }
        })
    } else {
        log.error("Remote Config could not be fetched. \(String(describing: error))")
    }
}

We call this part of the code only one, in AppDelegate during didFinishLaunchingWithOptions

In the wild, we see lots of Remote config errors reported, they're pretty straightforward:

ActivationFailureReason: Most recently fetched config is already activated
Code: 8003

Is it an error to try to activate fetched config when it's the same as active one? If yes, which approach should we take?
We can't use the fetchAndActivate since it doesn't have the expirationDuration parameter.

[morganchen12]

If your goal is to make sure the values in RemoteConfig are up-to-date, this code will work and you can ignore the error.

@dmandar is this intentional? If we have an error that we recommend users ignore, can we downgrade the error to an info/debug log instead?

[dmandar]

The error object always contains a value when activation cannot succeed. In this case, the already fetched config (present in the cache) is also already activated and no new activation can take place. If you prefer, you can use fetchAndActivate by pre-configuring the fetchInterval in the configSettings at initialization time which returns more granular status regarding whether both remote fetch and activate succeeded.

[schlingding]

We use this exact same method as well... not sure why this issue was closed. We need to utilize expirationDuration and this error is an unwanted side effect. I can't imagine developers wanting to create a code smell just to ignore this message.

I agree with @morganchen12 's approach of logging instead. This is NOT an error.

[dmandar]

Thanks for the feedback. We are working on improving the return status of the existing API. In the meantime, if appropriate, please use the new fetchAndActivate API which should have more granular status.

[paulb777]

There is already a warning logged at https://github.com/firebase/firebase-ios-sdk/blob/master/FirebaseRemoteConfig/Sources/FIRRemoteConfig.m#L298.

Why not pass nil to the completion handler at https://github.com/firebase/firebase-ios-sdk/blob/master/FirebaseRemoteConfig/Sources/FIRRemoteConfig.m#L308?

The functionality should be exactly the same as the success case.

[ashwinraghav]

Fwiw, On Android, it seems like we have a bool that indicates whether it was already activated
https://github.com/firebase/firebase-android-sdk/blob/2d3b7c25070d21f2058c5471c1831f7d8ac065fd/firebase-config/src/main/java/com/google/firebase/remoteconfig/FirebaseRemoteConfig.java#L233