Remote config returns stale value

[Akash-Panigrahi]

Operating System

macOS 14.5

Browser Version

Chrome/123.0.6312.87

Firebase SDK Version

10.12.2

Firebase SDK Product:

Analytics, Remote-Config

Describe your project's tooling

Simple JS app with the parcel as the bundler

Describe the problem

Remote config fetchAndActivate returns previous results even when minimumFetchIntervalMillis is set to 0. I am trying to use a feature flag with a custom properties set. This is being used in a web app.

Steps and code to reproduce issue

https://codesandbox.io/p/devbox/sparkling-https-nxwd7x?file=%2Fsrc%2Findex.mjs%3A35%2C1

The output is logged in the console. Using setUserProperties, I am accepting different values from remote-config. I have set two simple conditions, that retrieve different segment_selection_variant based on ProfileID.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[jbalidiong]

Hi @Akash-Panigrahi, apologies for the delay. I'm wasn't able to reproduce the behavior that you've mentioned. Let me know if I may have misunderstood anything, I tried following your code implementation and running the app. Here's what I did on my end:

1. Load the app with parceljs
2. The initial remote config value is B.
3. Change remote config value to A.

Checking the logs, it reflects the actual values upon changing in the console. You've mentioned the stale value of the remote config, are you seeing this upon changing in the console and refreshing the app? Can you also provide the steps on how to replicate the issue including the remote config value in the console.

[Akash-Panigrahi]

@jbalidiong Hey, thanks for checking this out.

The yellow marked boxes make up the first request and the blue ones form another.

• The expectedOutput and actualOutput for the yellow one is B.
• For the blue, the expectedOutput is A while the actualOutput is B, which is wrong.
  • This is picking the cached value from the first request.

[jbalidiong]

I conducted additional tests, but I still wasn’t able to recreate the behavior. I observed that the condition was not being met and resulting in the default value being used. Maybe our remote config setup is different. If you could provide a sample, that would be great. We could also check the analytics data associated with this condition. If you’re not comfortable with sharing additional information in this channel, you may reach out to our Firebase support team. You can provide them debug logs related to analytics and the remote config setup.

[Akash-Panigrahi]

I have changed the in-app default value to C for better debugging.

And here is the config JSON from the Firebase console.

{
  "conditions": [
    {
      "name": "Variant A",
      "expression": "app.userProperty['ProfileID'].exactlyMatches(['3806587'])",
      "tagColor": "BROWN"
    },
    {
      "name": "Variant B",
      "expression": "app.userProperty['ProfileID'].exactlyMatches(['3806585'])",
      "tagColor": "GREEN"
    }
  ],
  "parameters": {
    "segment_selection_variant": {
      "defaultValue": {
        "useInAppDefault": true
      },
      "conditionalValues": {
        "Variant A": {
          "value": "A"
        },
        "Variant B": {
          "value": "B"
        }
      },
      "valueType": "STRING"
    }
  },
  "version": {
    "versionNumber": "5",
    "updateTime": "2024-06-25T09:30:18.474116Z",
    "updateUser": {
      "email": ""
    },
    "updateOrigin": "CONSOLE",
    "updateType": "INCREMENTAL_UPDATE"
  }
}

The process is very straightforward. I call setUserProperties to set the user and call fetchAndActivate to get the corresponding remote config value.

For the first call it works, but for the next user, it gets the value of the first user. This should not happen.

[jbalidiong]

Apologies for the late response. I was able to replicate the reported behavior and discussed this issue with our Remote Config engineers. Upon investigation, this is working as intended behavior on web. We verified that it works, but only after some time and it is unpredictable. Checking our Google Analytics docs, it can take several hours for a property to be available for targeting.

It explained on the Google Analytics docs regarding the context of GA reporting and worth adding in the Remote Config side to prevent confusion. We'll be updating our documentation regarding this matter. With that, I'll be closing this issue now. If you encounter another issue, feel free to create a new one.